On Tue, Nov 16, 2010 at 09:28:14PM -0500, Josef Bacik wrote: > 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, > Sorry child induced sleep deprevation bleeding in there, that should read "I have no strong opinions one way or the other." Sheesh, 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
