So, you mean alternation of the refreservation mechanism to provide a possibility to refreserve space per-file, right? I'll investigate the idea. Thanks, Daniil Lunev.
On Tue, Oct 28, 2014 at 11:13 PM, Richard Elling <[email protected]> wrote: > > 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 >>> <https://www.listbox.com/member/archive/182179/=now> >>> <https://www.listbox.com/member/archive/rss/182179/22416196-0ceddc2d> | >>> Modify <https://www.listbox.com/member/?&;> Your Subscription >>> <http://www.listbox.com/> >>> >> >> *illumos-developer* | Archives >> <https://www.listbox.com/member/archive/182179/=now> >> <https://www.listbox.com/member/archive/rss/182179/22508062-ce4c709a> | >> Modify <https://www.listbox.com/member/?&;> Your Subscription >> <http://www.listbox.com/> >> >> >> *illumos-developer* | Archives >> <https://www.listbox.com/member/archive/182179/=now> >> <https://www.listbox.com/member/archive/rss/182179/22416196-0ceddc2d> | >> Modify >> <https://www.listbox.com/member/?member_id=22416196&id_secret=22416196-37d35730> >> Your Subscription <http://www.listbox.com/> >> > > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
