login
Header Space

 
 

Re: [RFC] add FIEMAP ioctl to efficiently map file allocation

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: David Chinner <dgc@...>
Cc: Nicholas Miell <nmiell@...>, <linux-ext4@...>, <linux-fsdevel@...>, <xfs@...>, <hch@...>
Date: Wednesday, May 2, 2007 - 5:45 am

On 2 May 2007, at 10:15, David Chinner wrote:

A concrete example:

Let's say that the FIEMAP interface goes live as is without any flags  
at all and just defined bits for "these are optional and those are  
compulsory".

Then the next kernel adds support for optional flag HSM_READ and  
compulsory flag XATTR_READ.

FS that do not support XATTR_READ will return -ENOTSUP as they cannot  
return the wanted data.

FS that do not support HSM_READ will still return the correct data in  
majority of cases (except when the FS supports HSM and the data is  
actually OFFLINE which the application will need to be able to cope  
with anyway incase the FS failed to bring the file ONLINE even if it  
supports the HSM_READ flag so no added complexity for handling this  
case).


Forgot to answer this bit:  This cannot happen.  There cannot be  
flags that move from compulsory to non-compulsory or anything stupid  
like that.  It would have to be a totally new flag otherwise it  
breaks backwards compatibility and hence this interface becomes  
useless crap.


So all applications end up doing:

if (version X, do blah)
else if (version Y, do blob)
else if (version Z, do foo)
else if (version A, do bar)
else exit(1);

Every time a new version is added?  And abort for unknown versions?   
Now that is a great interface!  Not.

Best regards,

	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/
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC] add FIEMAP ioctl to efficiently map file allocation, Andreas Dilger, (Thu Apr 12, 7:05 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Wed May 2, 4:23 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Wed May 2, 5:56 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Wed May 2, 4:30 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Tue May 1, 2:37 pm)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Wed May 2, 4:16 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Tue May 1, 2:46 pm)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Wed May 2, 5:45 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Wed May 2, 5:36 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Thu May 3, 4:23 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Wed May 2, 7:17 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Christoph Hellwig, (Fri Apr 13, 6:15 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Fri Apr 13, 7:38 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Thu Apr 12, 7:22 am)
Re: [RFC] add FIEMAP ioctl to efficiently map file allocation, Anton Altaparmakov, (Fri Apr 13, 3:46 am)
speck-geostationary