Andreas Dilger <adil...@dilger.ca> wrote:
> I'd be happy to have a proper SEEK_HOLE/SEEK_DATA implementation for
> Lustre, though it would be a bit tricky for sparse files striped over
> multiple OSTs. Probably the best way to handle this would be to
> fetch the FIEMAP data for each stripe to the client, and then interleave
> the extents on stripe_size boundaries (in file offset order) to determine
> where the actual holes/data are.
Given the fact that any filesystem needs to be implemented in a way that allows
to read data from files, I see no reason why there should be a problem on
lustre.
If you read data from disk blocks, you are not inside a hole and if the data
is synthesized nulls, you are inside a hole.
Now the filesystem only needs to be able to scan the block allocation tables.
Regardless of how inefficient the filesystem is implemented in how it knows
where to read data from, SEEK_HOLE will always be faster than reading data.
Jörg
--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
