|To:||David Chinner <dgc@xxxxxxx>|
|Subject:||Re: [RFC] add FIEMAP ioctl to efficiently map file allocation|
|From:||Anton Altaparmakov <aia21@xxxxxxxxx>|
|Date:||Tue, 1 May 2007 19:46:53 +0100|
|Cc:||Nicholas Miell <nmiell@xxxxxxxxxxx>, linux-ext4@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, hch@xxxxxxxxxxxxx|
|References:||<20070412110550.GM5967@schatzie.adilger.int> <20070416112252.GJ48531920@melbourne.sgi.com> <20070419002139.GK5967@schatzie.adilger.int> <20070419015426.GM48531920@melbourne.sgi.com> <20070430224401.GX5967@schatzie.adilger.int> <20070501042254.GD77450368@melbourne.sgi.com> <1177994346.3362.5.camel@entropy> <20070501142049.GG77450368@melbourne.sgi.com>|
On 1 May 2007, at 15:20, David Chinner wrote:
On Mon, Apr 30, 2007 at 09:39:06PM -0700, Nicholas Miell wrote:On Tue, 2007-05-01 at 14:22 +1000, David Chinner wrote:On Mon, Apr 30, 2007 at 04:44:01PM -0600, Andreas Dilger wrote:This is actually for future use. Any flags that are added into this
You are wrong about this because you are missing the point that you have no code to review. The users that will use those flags are going to be applications that run in user space. Chances are you will never see their code. Heck, they might not even be open source applications... And all applications will run against a multitude of kernels. So version X of the application will run on kernel 2.4.*, 2.6.*, a.b.*, etc... For future expandability of the interface I think it is important to have both compulsory and non-compulsory flags.
For example there is no reason why FIEMAP_HSM_READ needs to be compulsory. Most filesystems do not support HSM so can safely ignore it. And applications that want to read/write the data locations that are obtained with the FIEMAP call will likely always supply FIEMAP_HSM_READ because they want to ensure the file is brought in if it is off line so they definitely want file systems that do not support this flag to ignore it.
And vice versa, an application might specify some weird and funky yet to be developed feature that it expects the FS to perform and if the FS cannot do it (either because it does not support it or because it failed to perform the operation) the application expects the FS to return an error and not to ignore the flag. An example could be the asked for FIEMAP_XATTR_FORK flag. If that is implemented, and the FS ignores it it will return the extent map for the file data instead of the XATTR_FORK! Not what the application wanted at all. Ouch! So this is definitely a compulsory flag if I ever saw one.
So as you see you must support both voluntary and compulsory flags...
Also consider what I said above about different kernels. A new feature is implemented in kernel 2.8.13 say that was not there before and an application is updated to use that feature. There will be lots of instances where that application will still be run on older kernels where this feature does not exist. Depending on the feature it may be quite sensible to simply ignore in the kernel that the application set an unknown flag whilst for a different feature it may be the opposite.
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:||Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov|
|Next by Date:||Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Andreas Dilger|
|Previous by Thread:||Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, David Chinner|
|Next by Thread:||Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, David Chinner|
|Indexes:||[Date] [Thread] [Top] [All Lists]|