On Sun, Jan 20, 2013 at 07:51:15PM -0800, Richard Elling wrote:
>
> 2. VAAI support.
>
>VAAI has 4 features, 3 of which have been in illumos for a long time. The
>remaining
>feature (SCSI UNMAP) was done by Nexenta and exists in their NexentaStor
>product,
>but the CEO ma
wrote:
> >It gets even better. Executables become part of the swap space via
> >mmap, so that if you have a lot of copies of the same process running in
> >memory, the executable bits don't waste any more space (well, unless you
> >use the sticky bit, although that might be deprecated, or if you
On Jan 29, 2013, at 6:08 AM, Robert Milkowski wrote:
>> From: Richard Elling
>> Sent: 21 January 2013 03:51
>
>> VAAI has 4 features, 3 of which have been in illumos for a long time. The
> remaining
>> feature (SCSI UNMAP) was done by Nexenta and exists in their NexentaStor
> product,
>> but th
> From: Robert Milkowski [mailto:rmilkow...@task.gda.pl]
>
> That is one thing that always bothered me... so it is ok for others, like
> Nexenta, to keep stuff closed and not in open, while if Oracle does it they
> are bad?
Oracle, like Nexenta, and my own company CleverTrove, and Microsoft, and
On 01/29/2013 03:08 PM, Robert Milkowski wrote:
>> From: Richard Elling
>> Sent: 21 January 2013 03:51
>> VAAI has 4 features, 3 of which have been in illumos for a long time. The
> remaining
>> feature (SCSI UNMAP) was done by Nexenta and exists in their NexentaStor
> product,
>> but the CEO made
>From: Richard Elling
>Sent: 21 January 2013 03:51
>VAAI has 4 features, 3 of which have been in illumos for a long time. The
remaining
>feature (SCSI UNMAP) was done by Nexenta and exists in their NexentaStor
product,
>but the CEO made a conscious (and unpopular) decision to keep that code
fro
On 01/29/2013 02:59 PM, Robert Milkowski wrote:
>>> It also has a lot of performance improvements and general bug fixes
>> in
>>> the Solaris 11.1 release.
>>
>> Performance improvements such as?
>
>
> Dedup'ed ARC for one.
> 0 block automatically "dedup'ed" in-memory.
> Improvements to ZIL perfo
> > It also has a lot of performance improvements and general bug fixes
> in
> > the Solaris 11.1 release.
>
> Performance improvements such as?
Dedup'ed ARC for one.
0 block automatically "dedup'ed" in-memory.
Improvements to ZIL performance.
Zero-copy zfs+nfs+iscsi
...
--
Robert Milkowski
h
On 2013-01-24 11:06, Darren J Moffat wrote:
On 01/24/13 00:04, Matthew Ahrens wrote:
On Tue, Jan 22, 2013 at 5:29 AM, Darren J Moffat
mailto:darr...@opensolaris.org>> wrote:
Preallocated ZVOLs - for swap/dump.
Darren, good to hear about the cool stuff in S11.
Yes, thanks, Darren :)
J
On 01/24/13 00:04, Matthew Ahrens wrote:
On Tue, Jan 22, 2013 at 5:29 AM, Darren J Moffat
mailto:darr...@opensolaris.org>> wrote:
Preallocated ZVOLs - for swap/dump.
Darren, good to hear about the cool stuff in S11.
Just to clarify, is this preallocated ZVOL different than the
prealloca
On Tue, Jan 22, 2013 at 5:29 AM, Darren J Moffat wrote:
> Preallocated ZVOLs - for swap/dump.
>
Darren, good to hear about the cool stuff in S11.
Just to clarify, is this preallocated ZVOL different than the preallocated
dump which has been there for quite some time (and is in Illumos)? Can you
>On 01/22/2013 10:50 PM, Gary Mills wrote:
>> On Tue, Jan 22, 2013 at 11:54:53PM +, Edward Ned Harvey
>> (opensolarisisdeadlongliveopensolari
s) wrote:
>> Paging out unused portions of an executing process from real memory to
>> the swap device is certainly beneficial. Swapping out complete
>
On 01/22/2013 10:50 PM, Gary Mills wrote:
> On Tue, Jan 22, 2013 at 11:54:53PM +, Edward Ned Harvey
> (opensolarisisdeadlongliveopensolaris) wrote:
> Paging out unused portions of an executing process from real memory to
> the swap device is certainly beneficial. Swapping out complete
> proces
> From: Gary Mills [mailto:gary_mi...@fastmail.fm]
>
> > In solaris, I've never seen it swap out idle processes; I've only
> > seen it use swap for the bad bad bad situation. I assume that's all
> > it can do with swap.
>
> You would be wrong. Solaris uses swap space for paging. Paging out
> u
Jim Klimov wrote:
On 2013-01-23 09:41, casper@oracle.com wrote:
Yes and no: the system reserves a lot of additional memory (Solaris
doesn't over-commits swap) and swap is needed to support those
reservations. Also, some pages are dirtied early on and never touched
again; those pages should
On 2013-01-23 09:41, casper@oracle.com wrote:
Yes and no: the system reserves a lot of additional memory (Solaris
doesn't over-commits swap) and swap is needed to support those
reservations. Also, some pages are dirtied early on and never touched
again; those pages should not be kept in memo
>IIRC dump is special.
>
>As for swap... really, you don't want to swap. If you're swapping you
>have problems. Any swap space you have is to help you detect those
>problems and correct them before apps start getting ENOMEM. There
>*are* exceptions to this, such as Varnish. For Varnish and any
On Tue, Jan 22, 2013 at 11:54:53PM +, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of Nico Williams
> >
> > As for swap... really, you don't want to swap. If you're sw
The discussion gets suddenly hot and interesting - albeit quite diverged
from the original topic ;)
First of all, as a disclaimer, when I have earlier proposed such changes
to datasets for swap (and maybe dump) use, I've explicitly proposed that
this be a new dataset type - compared to zvol and f
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Nico Williams
>
> As for swap... really, you don't want to swap. If you're swapping you
> have problems.
For clarification, the above is true in Solaris and derivatives, but it's not
unive
On 01/22/2013 11:22 PM, Jim Klimov wrote:
> On 2013-01-22 23:03, Sašo Kiselkov wrote:
>> On 01/22/2013 10:45 PM, Jim Klimov wrote:
>>> On 2013-01-22 14:29, Darren J Moffat wrote:
Preallocated ZVOLs - for swap/dump.
>>>
>>> Or is it also supported to disable COW for such datasets, so that
>>> t
On 2013-01-22 23:32, Nico Williams wrote:
IIRC dump is special.
As for swap... really, you don't want to swap. If you're swapping you
have problems. Any swap space you have is to help you detect those
problems and correct them before apps start getting ENOMEM. There
*are* exceptions to this,
IIRC dump is special.
As for swap... really, you don't want to swap. If you're swapping you
have problems. Any swap space you have is to help you detect those
problems and correct them before apps start getting ENOMEM. There
*are* exceptions to this, such as Varnish. For Varnish and any other
On 2013-01-22 23:03, Sašo Kiselkov wrote:
On 01/22/2013 10:45 PM, Jim Klimov wrote:
On 2013-01-22 14:29, Darren J Moffat wrote:
Preallocated ZVOLs - for swap/dump.
Or is it also supported to disable COW for such datasets, so that
the preallocated swap/dump zvols might remain contiguous on the
On 01/22/2013 10:45 PM, Jim Klimov wrote:
> On 2013-01-22 14:29, Darren J Moffat wrote:
>> Preallocated ZVOLs - for swap/dump.
>
> Or is it also supported to disable COW for such datasets, so that
> the preallocated swap/dump zvols might remain contiguous on the
> faster tracks of the drive (i.e.
Darren J Moffat wrote:
It is a mechanism for part of the storage system above the "disk" (eg
ZFS) to inform the "disk" that it is no longer using a given set of blocks.
This is useful when using an SSD - see Saso's excellent response on that.
However it can also be very useful when your "disk"
On 2013-01-22 14:29, Darren J Moffat wrote:
Preallocated ZVOLs - for swap/dump.
Sounds like something I proposed on these lists, too ;)
Does this preallocation only mean filling an otherwise ordinary
ZVOL with zeroes (or some other pattern) - if so, to what effect?
Or is it also supported to d
On 01/22/2013 05:34 PM, Darren J Moffat wrote:
>
>
> On 01/22/13 16:02, Sašo Kiselkov wrote:
>> On 01/22/2013 05:00 PM, casper@oracle.com wrote:
Some vendors call this (and thins like it) "Thin Provisioning", I'd say
it is more "accurate communication between 'disk' and filesystem"
On 01/22/13 16:02, Sašo Kiselkov wrote:
On 01/22/2013 05:00 PM, casper@oracle.com wrote:
Some vendors call this (and thins like it) "Thin Provisioning", I'd say
it is more "accurate communication between 'disk' and filesystem" about
in use blocks.
In some cases, users of disks are charge
On 01/22/2013 05:00 PM, casper@oracle.com wrote:
>> Some vendors call this (and thins like it) "Thin Provisioning", I'd say
>> it is more "accurate communication between 'disk' and filesystem" about
>> in use blocks.
>
> In some cases, users of disks are charged by bytes in use; when not usi
>Some vendors call this (and thins like it) "Thin Provisioning", I'd say
>it is more "accurate communication between 'disk' and filesystem" about
>in use blocks.
In some cases, users of disks are charged by bytes in use; when not using
SCSI UNMAP, a set of disks used for a zpool will in the en
On 01/22/13 15:32, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
From: Darren J Moffat [mailto:darr...@opensolaris.org]
Support for SCSI UNMAP - both issuing it and honoring it when it is the
backing store of an iSCSI target.
When I search for scsi unmap, I come up with al
Edward Ned Harvey (opensolarisisdeadlongliveopensolaris) wrote:
From: Darren J Moffat [mailto:darr...@opensolaris.org]
Support for SCSI UNMAP - both issuing it and honoring it when it is the
backing store of an iSCSI target.
When I search for scsi unmap, I come up with all sorts of docume
On 01/22/2013 04:32 PM, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
>> From: Darren J Moffat [mailto:darr...@opensolaris.org]
>>
>> Support for SCSI UNMAP - both issuing it and honoring it when it is the
>> backing store of an iSCSI target.
>
> When I search for scsi unmap, I c
> From: Darren J Moffat [mailto:darr...@opensolaris.org]
>
> Support for SCSI UNMAP - both issuing it and honoring it when it is the
> backing store of an iSCSI target.
When I search for scsi unmap, I come up with all sorts of documentation that
... is ... like reading a medical journal when all
On Mon, 21 Jan 2013, Jim Klimov wrote:
Yes, maybe there were more "cool new things" per year popping up
with Sun's concentrated engineering talent and financing, but now
it seems that most players - wherever they work now - took a pause
from the marathon, to refine what was done in the decade be
>On 01/22/2013 02:39 PM, Darren J Moffat wrote:
>>
>> On 01/22/13 13:29, Darren J Moffat wrote:
>>> Since I'm replying here are a few others that have been introduced in
>>> Solaris 11 or 11.1.
>>
>> and another one I can't believe I missed since I was one of the people
>> that helped design it
On 01/22/2013 02:39 PM, Darren J Moffat wrote:
>
> On 01/22/13 13:29, Darren J Moffat wrote:
>> Since I'm replying here are a few others that have been introduced in
>> Solaris 11 or 11.1.
>
> and another one I can't believe I missed since I was one of the people
> that helped design it and I did
On 01/22/13 13:29, Darren J Moffat wrote:
Since I'm replying here are a few others that have been introduced in
Solaris 11 or 11.1.
and another one I can't believe I missed since I was one of the people
that helped design it and I did codereview...
Per file sensitively labels for TX configu
On 01/22/13 13:29, Sašo Kiselkov wrote:
On 01/22/2013 02:20 PM, Michel Jansens wrote:
Maybe 'shadow migration' ? (eg: zfs create -o shadow=nfs://server/dir
pool/newfs)
Hm, interesting, so it works as a sort of replication system, except
that the data needs to be read-only and you can start
On 01/22/2013 02:20 PM, Michel Jansens wrote:
>
> Maybe 'shadow migration' ? (eg: zfs create -o shadow=nfs://server/dir
> pool/newfs)
Hm, interesting, so it works as a sort of replication system, except
that the data needs to be read-only and you can start accessing it on
the target before the i
On 01/22/13 13:20, Michel Jansens wrote:
Maybe 'shadow migration' ? (eg: zfs create -o shadow=nfs://server/dir
pool/newfs)
That isn't really a ZFS feature, since it happens at the VFS layer. The
ZFS support there is really about getting the options passed through and
checking status but t
Maybe 'shadow migration' ? (eg: zfs create -o shadow=nfs://server/dir
pool/newfs)
Michel
On 01/21/13 17:03, Sašo Kiselkov wrote:
Again, what significant features did they add besides encryption? I'm
not saying they didn't, I'm just not aware of that many.
Just a few examples:
Solaris Z
On 01/22/13 11:57, Tomas Forsman wrote:
On 22 January, 2013 - Darren J Moffat sent me these 0,6K bytes:
On 01/21/13 17:03, Sa?o Kiselkov wrote:
Again, what significant features did they add besides encryption? I'm
not saying they didn't, I'm just not aware of that many.
Just a few examples
On 01/22/2013 12:30 PM, Darren J Moffat wrote:
> On 01/21/13 17:03, Sašo Kiselkov wrote:
>> Again, what significant features did they add besides encryption? I'm
>> not saying they didn't, I'm just not aware of that many.
>
> Just a few examples:
>
> Solaris ZFS already has support for 1MB block
On 22 January, 2013 - Darren J Moffat sent me these 0,6K bytes:
> On 01/21/13 17:03, Sa?o Kiselkov wrote:
>> Again, what significant features did they add besides encryption? I'm
>> not saying they didn't, I'm just not aware of that many.
>
> Just a few examples:
>
> Solaris ZFS already has suppor
On 01/21/13 17:03, Sašo Kiselkov wrote:
Again, what significant features did they add besides encryption? I'm
not saying they didn't, I'm just not aware of that many.
Just a few examples:
Solaris ZFS already has support for 1MB block size.
Support for SCSI UNMAP - both issuing it and honoring
On 01/22/2013 03:56 AM, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
>> From: Sašo Kiselkov [mailto:skiselkov...@gmail.com]
>>
>> as far as incompatibility among products, I've yet to come
>> across it
>
> I was talking about ... install solaris 11, and it's using a new version
> From: Sašo Kiselkov [mailto:skiselkov...@gmail.com]
>
> as far as incompatibility among products, I've yet to come
> across it
I was talking about ... install solaris 11, and it's using a new version of zfs
that's incompatible with anything else out there. And vice-versa. (Not sure
if featu
On 01/21/2013 02:28 PM, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
>> From: Richard Elling [mailto:richard.ell...@gmail.com]
>>
>> I disagree the ZFS is developmentally challenged.
>
> As an IT consultant, 8 years ago before I heard of ZFS, it was always easy
> to sell Ontap,
Zfs on linux (ZOL) has made some pretty impressive strides over the last
year or so...
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> I disagree the ZFS is developmentally challenged.
As an IT consultant, 8 years ago before I heard of ZFS, it was always easy to
sell Ontap, as long as it fit into the budget. 5 years ago, whenever I told
customers about ZFS, it was
On Jan 20, 2013, at 4:51 PM, Tim Cook wrote:
> On Sun, Jan 20, 2013 at 6:19 PM, Richard Elling
> wrote:
> On Jan 20, 2013, at 8:16 AM, Edward Harvey wrote:
> > But, by talking about it, we're just smoking pipe dreams. Cuz we all know
> > zfs is developmentally challenged now. But one can dr
On Sun, Jan 20, 2013 at 6:19 PM, Richard Elling wrote:
> On Jan 20, 2013, at 8:16 AM, Edward Harvey
> wrote:
> > But, by talking about it, we're just smoking pipe dreams. Cuz we all
> know zfs is developmentally challenged now. But one can dream...
>
> I disagree the ZFS is developmentally chal
On 2013-01-20 17:16, Edward Harvey wrote:
But, by talking about it, we're just smoking pipe dreams. Cuz we all know zfs
is developmentally challenged now. But one can dream...
I beg to disagree. While most of my contribution was so far about
learning stuff and sharing with others, as well as
On Jan 20, 2013, at 8:16 AM, Edward Harvey wrote:
> But, by talking about it, we're just smoking pipe dreams. Cuz we all know
> zfs is developmentally challenged now. But one can dream...
I disagree the ZFS is developmentally challenged. There is more development
now than ever in every way: #
On 2013-01-20 19:55, Tomas Forsman wrote:
On 19 January, 2013 - Jim Klimov sent me these 2,0K bytes:
Hello all,
While revising my home NAS which had dedup enabled before I gathered
that its RAM capacity was too puny for the task, I found that there is
some deduplication among the data bits
On 19 January, 2013 - Jim Klimov sent me these 2,0K bytes:
> Hello all,
>
> While revising my home NAS which had dedup enabled before I gathered
> that its RAM capacity was too puny for the task, I found that there is
> some deduplication among the data bits I uploaded there (makes sense,
> sinc
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Nico Williams
>
> To decide if a block needs dedup one would first check the Bloom
> filter, then if the block is in it, use the dedup code path, else the
> non-dedup codepath and insert the bl
Bloom filters are very small, that's the difference. You might only need a
few bits per block for a Bloom filter. Compare to the size of a DDT entry.
A Bloom filter could be cached entirely in main memory.
___
zfs-discuss mailing list
zfs-discuss@opens
So ... The way things presently are, ideally you would know in advance what
stuff you were planning to write that has duplicate copies. You could enable
dedup, then write all the stuff that's highly duplicated, then turn off dedup
and write all the non-duplicate stuff. Obviously, however, this
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Nico Williams
>
> I've wanted a system where dedup applies only to blocks being written
> that have a good chance of being dups of others.
>
> I think one way to do this would be to keep a sca
bloom filters are a great fit for this :-)
-- richard
On Jan 19, 2013, at 5:59 PM, Nico Williams wrote:
> I've wanted a system where dedup applies only to blocks being written
> that have a good chance of being dups of others.
>
> I think one way to do this would be to keep a scalable Bloo
I've wanted a system where dedup applies only to blocks being written
that have a good chance of being dups of others.
I think one way to do this would be to keep a scalable Bloom filter
(on disk) into which one inserts block hashes.
To decide if a block needs dedup one would first check the Bloo
Hello all,
While revising my home NAS which had dedup enabled before I gathered
that its RAM capacity was too puny for the task, I found that there is
some deduplication among the data bits I uploaded there (makes sense,
since it holds backups of many of the computers I've worked on - some
of m
65 matches
Mail list logo
