|To:||Andreas Dilger <adilger@xxxxxxxxxxxxx>|
|Subject:||Re: [RFC] add FIEMAP ioctl to efficiently map file allocation|
|From:||Anton Altaparmakov <aia21@xxxxxxxxx>|
|Date:||Fri, 13 Apr 2007 08:46:18 +0100|
|Cc:||linux-ext4@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, hch@xxxxxxxxxxxxx|
|References:||<20070412110550.GM5967@schatzie.adilger.int> <97211C89-1810-4B22-B2F4-9D206D43C1F6@cam.ac.uk> <20070413040156.GU5967@schatzie.adilger.int>|
On 13 Apr 2007, at 05:01, Andreas Dilger wrote:
On Apr 12, 2007 12:22 +0100, Anton Altaparmakov wrote:On 12 Apr 2007, at 12:05, Andreas Dilger wrote:I'm interested in getting input for implementing an ioctl to efficiently map file extents & holes (FIEMAP) instead of looping over FIBMAP a billion times. We already have customers with single files in the 10TB range and we additionally need to get the mapping over the network so it needs to be efficient in terms of how data is passed, and how easily it can be extracted from the filesystem.
Sure, hence why I made my comment for NTFS. (-: And yes, ReiserFS and even ext* could use such flag. I believe there is a compression patch for ext somewhere isn't there? (Or at least there was one at some point I think...)
Also why are you not using 0xff00000000000000, i.e. two more zeroes at the end? Seems unnecessary to drop an extra 8 bits of significance from the byte size...
That said, I think that 2^48 bytes is probably sufficient for most uses,
Valid point. As long as the "on-disk location" is maintained as full 64 bits then you are right we could just return multiple extents if the space does not fit. A bit of a kludge but it would certainly work. An alternative would be to have the flags in a separate field but that would add 8-bytes to the structure size if you want to maintain 8-byte alignment so that would not be great...
At most we'd have to call the ioctl() 65536 times for a completely
Yes, NTFS also has off line storage (DFS - the Distributed File System I think it is called) but we don't support any of that. Perhaps one day...
This concept is also present in XFS_IOC_GETBMAPX - BMV_IF_NO_DMAPI_READ,
It is standard on Unix. I am trying to fight this standard because of NTFS... On NTFS a hole is -1 not 0 and zero is a valid block. But on NTFS device locations are "s64" not "u64" so the -1 is logical to use...
As long as it is made clear that people MUST check the flag when fe_start == 0 rather than assume that fe_start == 0 means a hole I am happy with that. Hopefully not too many programmers will be lazy gits who will ignore this and just check fe_start == 0 or they will fail on NTFS and assume $Boot is sparse when it is not...
PS - I'd thought about adding you to the CC list for this, because I know
Thanks. Yes, I try to follow fsdevel closely and LKML not so closely (I often read it with "select all new, delete")...
Thanks for your input.
Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||[PATCH] xfs_repair - move realtime extent processing to a separate function, Barry Naujok|
|Next by Date:||Re: [PATCH] remove the unnecessary word in the log message., Christoph Hellwig|
|Previous by Thread:||Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Andreas Dilger|
|Next by Thread:||Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Jeff Mahoney|
|Indexes:||[Date] [Thread] [Top] [All Lists]|