On Wed, 26 Feb 2014 12:34:26 +1100 Dave Chinner [off-list ref] wrote:

On Tue, Feb 25, 2014 at 03:41:28PM -0800, Andrew Morton wrote:

quoted

On Tue, 25 Feb 2014 15:23:35 -0800 (PST) Hugh Dickins [off-list ref] wrote:

quoted

On Tue, 25 Feb 2014, Dave Chinner wrote:

quoted

On Tue, Feb 25, 2014 at 02:16:01PM +1100, Stephen Rothwell wrote:

quoted

On Mon, 24 Feb 2014 11:57:10 +1100 Dave Chinner [off-list ref] wrote:

FALLOC_FL_COLLAPSE_RANGE: I'm a little sad at the name COLLAPSE,
but probably seven months too late to object.  It surprises me that
you're doing all this work to deflate a part of the file, without
the obvious complementary work to inflate it - presumably all those
advertisers whose ads you're cutting out, will come back to us soon
to ask for inflation, so that they have somewhere to reinsert them ;)

Yes, I was wondering that.  Why not simply "move these blocks from here
to there".

And open a completely unnecessary can of worms to do with
behavioural and implementation corner cases?

But it's general.

Do you allow it to destroy data by default? Or only allow moves into
holes?

Overwrite.

What do you do with range the data is moved out of? Does it just
become a hole? What happens if the range overlaps EOF - does that
change the file size?

Truncate.

What if you want to move the range beyond EOF?

Extend.

What if the source and destination ranges overlap?

Don't screw it up.

What happens when you move the block at EOF into the middle of a
file - do you end up with zeros padding the block and the file size
having to be adjusted accordingly? Or do we have to *copy* all the
data in high blocks down to fill the hole in the block?

I don't understand that.  Move the block(s) and truncate to the new
length.

What behaviour should we expect if the filesystem can't implement
the entire move atomically and we crash in the middle of the move?

What does collapse_range do now?

If it's a journaled filesystem, it shouldn't screw up.  If it isn't, fsck.

I can keep going, but I'll stop here - you get the idea.

None of this seems like rocket science.

In comparison, collapse range as a file data manipulation has very
specific requirements and from that we can define a simple, specific
API that allows filesystems to accelerate that operation by extent
manipulation rather than read/memcpy/write that the applications are
currently doing for this operation....  IOWs, collapse range is a
simple operation, "move arbitrary blocks from here to there" is a
nightmare both from the specification and the implementation points
of view.

collapse_range seems weird, arbitrary and half-assed.  "Why didn't they
go all the way and do it properly".

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs