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 > > >(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
