On Oct 28, 2014, at 9:02 AM, Daniil Lunev via illumos-developer <[email protected]> wrote:
> >(1) When a leaf block is filled in, the BP with the bit set is COW'd without > > the bit set. Correct? > Correct. > > >(2) Why even bother writing out the non-leaf blocks? Wouldn't just > Some applications require space to be fully allocated at the creation time > and checks both file size and disk space consumption. Really? Those developers should be publicly humilated into bankruptcy. Sparse files have been available for decades and if you can't deal with the file length != size, then just go back to DOS and leave the modern world alone. > > >(3) What sort of workload is this supposed to accelerate? I understand that > File thick provisioning VMware? > > >(4)Is the idea to reduce fragmentation? > No, it is not. > > >(1) I like VERIFY0/ASSERT0 (or VERIFY3*/ASSERT3* with == 0) over ASSERT(0 == > Which assertions do not satisfy your expectation? > > >(2) zio.c:1170: Pretty sure the second part of the condition is wrong due to > Good catch, it is a typo, Webrev is updated. > > >I would echo Jeff's questions about what the use case is here. > > >Is the goal to reserve space for individual files, and doing so physically > >(as opposed to logically, like filesystem reservations) was the easiest way > >to implement it? Did you investigate >implementing a logical per-file > >reservation? A logical reservation should perform better (both when setting > >the reservation, and when writing, since there would be more physical free > >space). > > >I think that logically, this is the equivalent of writing zeros to the file. > > How does this interact with compression? Normally, writing zeros to a > >compressed file will result in hole blocks being >created. Is the idea that > >this feature is only intended to be used with compression disabled? > > The usecase is to speed up thick provisioning and to be honest provisioner. > It is equiualent to writing zeroes with compression turned off (if block is > reserved, the compression and checksumming for the block are set `off`). The > point is to asure the application that the file is completely writeable at > any time. This won't work if you take a snapshot. Just let us know who to humiliate... -- richard > > On Tue, Oct 28, 2014 at 7:40 PM, Matthew Ahrens via illumos-developer > <[email protected]> wrote: > I would echo Jeff's questions about what the use case is here. > > Is the goal to reserve space for individual files, and doing so physically > (as opposed to logically, like filesystem reservations) was the easiest way > to implement it? Did you investigate implementing a logical per-file > reservation? A logical reservation should perform better (both when setting > the reservation, and when writing, since there would be more physical free > space). > > I think that logically, this is the equivalent of writing zeros to the file. > How does this interact with compression? Normally, writing zeros to a > compressed file will result in hole blocks being created. Is the idea that > this feature is only intended to be used with compression disabled? > > --matt > > On Tue, Oct 28, 2014 at 5:20 AM, Daniil Lunev <[email protected]> > wrote: > Hello, all! > Here is the patch which adds in ZFS feature to physically reserve space for > files, i.e. thick provision > > http://cr.illumos.org/~webrev/DKOI/reservation/ > > The patch adds a new IOCTL for files residing on ZFS filesystems, which > performs reservation. The reservation is done by emulating writes for the > whole range which need to be reserved, except leaf blocks are not physically > written - they are allocated and the blockpointers, which point to them, are > marked to be reserved. For marking, the currently unused in illumos 61th bit > is used. Tests show at least 4 times speed up of providing thick files > comparing to sequential writes of zero blocks. > > Thanks, > Daniil Lunev > > illumos-developer | Archives | Modify Your Subscription > > illumos-developer | Archives | Modify Your Subscription
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
