On 05/02/11 14:02, Nico Williams wrote:
Also, sparseness need not be apparent to applications. Until recent
improvements to lseek(2) to expose hole/non-hole offsets, the only way
to know about sparseness was to notice that a file's reported size is
more than the file's reported filesystem blocks times the block size.
Sparse files in Unix go back at least to the early 80s.
If a filesystem protocol, such as CIFS (I've no idea if it supports
sparse files), were to not support sparse files, all that would mean
is that the server must report a number of blocks that matches a
file's size (assuming the protocol in question even supports any
notion of reporting a file's size in blocks).
There's really two ways in which a filesystem protocol could support
sparse files: a) by reporting file size in bytes and blocks, b) by
reporting lists of file offsets demarcating holes from non-holes. (b)
is a very new idea; Lustre may be the only filesystem that I know that
supports this (see the Linux FIEMAP APIs)., though work is in progress
to add this to NFSv4.
I enhanced the lseek interface a while back now to return information
about sparse
files, by adding 2 new interfaces: SEEK_HOLE and SEEK_DATA. See
man -s2 lseek
Neil.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
