On Oct 28, 2014, at 10:36 AM, Daniil Lunev <[email protected]> wrote:
> > On Tue, Oct 28, 2014 at 8:41 PM, Richard Elling via illumos-developer > <[email protected]> wrote: > 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? > > Answer for both question > Non-sparse space allocation to support VMware (NAS VAAI spec) and Citrix, > likely OpenStack in the near future. Without this patch random data has to be > generate to _actually_ allocate space This requirement stems from the non-ZFS world where assumptions are made about how files are stored and space is accounted. The same is true of posix_fallocate(). And yes, they should be publicly humiliated. For the virtual disk use case, while the pedantic answer is to adjust the refreservation for the dataset, the non-ZFSers will never understand. Rather than faking it, why not simply change the refreservation? -- richard >> >> >(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 > > Yes, agree. With snapshots it is possible not to be able to rewrite the file > even in this case, Whose to blame? See answer for the previous question for > motivation.. > >> >> 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 > > illumos-developer | Archives | Modify Your Subscription >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
