Hello zfs-discuss,
When compression is set to on for a givef file system, then if
block contains only 0s "nothing" is writen. I wonder if it would be
beneficial if ZFS behaves that way not only for block which are
going to be compressed but for all block regardless of compression.
Or perhaps making this simple check would too much impact CPU for
normal data?
?
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
> When compression is set to on for a givef file system, then if > block contains only 0s "nothing" is writen. I wonder if it would be > beneficial if ZFS behaves that way not only for block which are > going to be compressed but for all block regardless of compression.Yes. We''re planning to fold the all-zero check into the checksum generation logic, so that whenever we compute a checksum we''ll also determine whether the block is all zeroes. If so, we''ll turn it into a hole -- whether compression is enabled or not. Jeff
Hello Jeff, Wednesday, December 21, 2005, 10:18:39 AM, you wrote:>> When compression is set to on for a givef file system, then if >> block contains only 0s "nothing" is writen. I wonder if it would be >> beneficial if ZFS behaves that way not only for block which are >> going to be compressed but for all block regardless of compression.JB> Yes. We''re planning to fold the all-zero check into the checksum JB> generation logic, so that whenever we compute a checksum we''ll also JB> determine whether the block is all zeroes. If so, we''ll turn it JB> into a hole -- whether compression is enabled or not. JB> Jeff Thanks for qick reply :) There could be one problem - if an application creates its files (filled with 0) and then want to modify - there simply could be no space left i a pool to just modify a file (as space is not reserved for this hole, right?). -- Best regards, Robert mailto:rmilkowski at task.gda.pl
>Thanks for qick reply :) > >There could be one problem - if an application creates its files >(filled with 0) and then want to modify - there simply could be no >space left i a pool to just modify a file (as space is not reserved >for this hole, right?).Well, that''s always the case with zfs; you cannot modify a block, the block needs to be rewritten. So if there is no space left, you cannot modify a file. But it is indeed possible that writing to a whole will push the fs over the limit where writing and freeing the 0 filled blocks would not. Similar things can happen with compressed files. Casper
Casper.Dik at Sun.COM wrote:> Well, that''s always the case with zfs; you cannot modify a block, the > block needs to be rewritten. So if there is no space left, you cannot > modify a file.Does this mean overwriting a file several times will make it fragmented over the disk? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>Casper.Dik at Sun.COM wrote: > >> Well, that''s always the case with zfs; you cannot modify a block, the >> block needs to be rewritten. So if there is no space left, you cannot >> modify a file. > >Does this mean overwriting a file several times will make it fragmented >over the disk?If you rewrite the file then all writes will be close to one another on disk; if you write different blocks at different times, then it stands to reason that the layout will be random (but a good prefetch algorithm helps there) Casper
Hello Casper, Wednesday, December 21, 2005, 11:48:39 AM, you wrote:>>Thanks for qick reply :) >> >>There could be one problem - if an application creates its files >>(filled with 0) and then want to modify - there simply could be no >>space left i a pool to just modify a file (as space is not reserved >>for this hole, right?).CDSC> Well, that''s always the case with zfs; you cannot modify a block, the CDSC> block needs to be rewritten. So if there is no space left, you cannot CDSC> modify a file. CDSC> But it is indeed possible that writing to a whole will push the fs CDSC> over the limit where writing and freeing the 0 filled blocks would not. CDSC> Similar things can happen with compressed files. Yeah, but - I''m not sure about databases what they are actually writing when creating new files but if these files are 0s it could be a little bit confusing to sys admins - after creating new 100GB database file (on a 200GB fs) there''s still almost nothing being used to sys admin puts more data and then suddenly realizing he''s out of space (when he actually imports data, etc.). On the other hand in many other scenarios making WHOLE instead of writing 0s would be preffered. Maybe some kind of switch/setting on given dataset? (I know self-tuning, etc. - but at the and better control means better fit). -- Best regards, Robert mailto:rmilkowski at task.gda.pl