On 26 March 2012 18:52, Henk Langeveld <[email protected]> wrote: > I remember SEEK_HOLE and SEEK_DATA being proposed by the creators of > ZFS. > ZFS is the first of various file systems allowing Copy on Write. In > order > to preserve the space savings after COW, it be a good thing for > utilities > to have a way of detecting block of zeroes. > > David describes how the AST utilities already were aware of holes in > data > when these were proposed.
I don't see how the AST commands are aware of holes. The AST commands try to turn larger areas of bytes to holes which is just wrong because it breaks the distinctive semantics between 'no data here' and 'bytes with value zero here'. This has been a pain for database and ERP vendors those products choke if the sparse files are damaged and a pain for customers if the sparse files don't work, for example SGI paid a dearly price when they introduced XFS without sparse file support by loosing many enterprise customers. Even twice - once sparse file support was broken and SGI was nearly sued out of existence. So this is very important for customers, enough to cause trouble for SGI, have ext3/ext4 add custom sparse file support by allowing applications access to the allocation bitmaps (this rather ugly and unportable interface was later superset by SEEK_HOLE/SEEK_DATA) and have the ZFS designers create the SEEK_HOLE/SEEK_DATA api. > So much better if sfio supports this out-of-the-box. Right. IMO explicit support for sparse files would benefit many commands, not only cp, mv, pax, e.g. cat, cmp and dd could benefit from SEEK_HOLE related optimizations if both input (and output, if applicable) files are seekable. _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
