On Wed, Nov 17, 2010 at 01:11:50PM +1100, Dave Chinner wrote: > On Tue, Nov 16, 2010 at 06:22:47PM -0600, Andreas Dilger wrote: > > On 2010-11-16, at 07:14, Jan Kara wrote: > > >> Yeah I went back and forth on this. KEEP_SIZE won't change the > > >> behavior of PUNCH_HOLE since PUNCH_HOLE implicitly means keep > > >> the size. I figured since its "mode" and not "flags" it would > > >> be ok to make either way accepted, but if you prefer PUNCH_HOLE > > >> means you have to have KEEP_SIZE set then I'm cool with that, > > >> just let me know one way or the other. > > > > > > So we call it "mode" but speak about "flags"? Seems a bit > > > inconsistent. I'd maybe lean a bit at the "flags" side and just > > > make sure that only one of FALLOC_FL_KEEP_SIZE, > > > FALLOC_FL_PUNCH_HOLE is set (interpreting FALLOC_FL_KEEP_SIZE as > > > allocate blocks beyond i_size). But I'm not sure what others > > > think. > > > > IMHO, it makes more sense for consistency and "get what users > > expect" that these be treated as flags. Some users will want > > KEEP_SIZE, but in other cases it may make sense that a hole punch > > at the end of a file should shrink the file (i.e. the opposite of > > an append). > > What's wrong with ftruncate() for this? > > There's plenty of open questions about the interface if we allow > hole punching to change the file size. e.g. where do we set the EOF > (offset or offset+len)? What do we do with the rest of the blocks > that are now beyond EOF? We weren't asked to punch them out, so do > we leave them behind? What if we are leaving written blocks beyond > EOF - does any filesystem other than XFS support that (i.e. are we > introducing different behaviour on different filesystems)? And what > happens if the offset is beyond EOF? Do we extend the file, and if > so why wouldn't you just use ftruncate() instead? > > IMO, allowing hole punching to change the file size makes it much > more complicated and hence less likely to simply do what the user > expects. It also is harder to implement and testing becomes much > more intricate. From that perspective, it does not seem desirable to > me... > FWIW I agree with Dave, the only question at this point is do we force users to specify KEEP_SIZE with PUNCH_HOLE? On one hand it makes the interface a bit more consistent, on the other hand it makes the documentation a little weird "We have mode here, but if you want to use PUNCH_HOLE you also have to specify KEEP_SIZE, so really it's like a flags field it's just named poorly" I have no strong opinions the other way so if nobody else does then I'll just do it Jan's way. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
