Date: Thu, 29 Mar 2012 12:14:15 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: fs@freebsd.org Subject: Re: RFC: SEEK_HOLE/SEEK_DATA common implementation Message-ID: <20120329091415.GA1316@reks> In-Reply-To: <20120327183440.GS2358@deviant.kiev.zoral.com.ua> References: <20120327183440.GS2358@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On (27/03/2012 21:34), Konstantin Belousov wrote: > Hello, > Please find at > http://people.freebsd.org/~kib/misc/seek_hole.1.patch > a prototype generic implementation of the SEEK_HOLE/SEEK_DATA lseek(2) > whence command for any filesystem that properly supports bmap. > > I was unable to find any test suite for the feature, and the only more > or less reasonable case I found was from lklm, extracted at > http://people.freebsd.org/~kib/misc/seek_hole.c > The block for file with hole at the end is commented out because > UFS never puts holes at EOF. The block_size is tuned for default block > size on UFS on recent FreeBSD. > > Filesystem-specific implementations could greatly increase the performance > of the call, because the presented implementation does linear search > through the blocks until hole/data boundary is found. E.g., for UFS, > the fast tree-like structure of indirect blocks can be traversed to > point at the next boundary. But this implementation is generic. What do you think about replacing FIOSEEKHOLE/FIOSEEKDATA ioctls with VOP_SEEKHOLE (or similar). That would be more straightforward. Currently there is no way for a file system to use standard SEEKHOLE implementation without invoking vop_stdioctl. It handles only FIOSEEKHOLE now but that is likely to change in future. I wish we had no default VOP_IOCTL implementation and keep it file system specific. We should also return valid _PC_MIN_HOLE_SIZE (=mnt_stat.f_iosize) in VOP_PATHCONF for userland to see SEEK_HOLE/SEEK_DATA support. I'm not sure enabling it by default is desirable, performance penalty can be considerable. Consider creating tar archive of large files with O(file size) SEEK_HOLE enabled. On the other hand default implementation can be useful, e.g. if file system had internal flag for sparse files it could simply reuse default vop_stdseekhole() avoiding overhead for non-sparse files. Thanks, Gleb. > > Please comment.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120329091415.GA1316>