>(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. >(3) What sort of workload is this supposed to accelerate? I understand that File thick provisioning >(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. 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/?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
