Finding the proper scope of a file collapse operation [LWN.net]

Finding the proper scope of a file collapse operation

Posted Mar 6, 2014 8:37 UTC (Thu) by fishface60 (subscriber, #88700)
Parent article: Finding the proper scope of a file collapse operation

I've got the sneaking suspicion that btrfs may already be able to do everything that's required, since it has an ioctl for cloning a range of data in a file, that can work on the same file.

I don't know if it'll handle moving nicely, but even if it doesn't, you can create a new copy of the file without the required range, by just cloning the data before and after into it, then replace your old file with the new one.

to post comments

Finding the proper scope of a file collapse operation

Posted Mar 6, 2014 12:08 UTC (Thu) by HIGHGuY (subscriber, #62277) [Link] (3 responses)

I would think Andrew's proposal is doable...

Insert range:
- add sufficient data to end of file using fallocate()
- move range into position

Remove range:
- move range to end of file
- truncate()

With regards to mmap(), tmpfs, etc. you don't need to care about writeback of dirty data, mmap resize, etc. You just swap the mapping of pages around and have truncate() and fallocate() do the hard stuff.

But then again, I'm not hindered by any knowledge on the subject...

Finding the proper scope of a file collapse operation

Posted Mar 6, 2014 14:58 UTC (Thu) by dgm (subscriber, #49227) [Link] (1 responses)

I seems that the basic code is already there. Why not just add a syscall to shuffle blocks around?

Finding the proper scope of a file collapse operation

Posted Mar 6, 2014 18:23 UTC (Thu) by Funcan (guest, #44209) [Link]

It's there for some filesystems. Not for most.

Finding the proper scope of a file collapse operation

Posted Mar 17, 2014 1:38 UTC (Mon) by vomlehn (guest, #45588) [Link]

I very much like Andrews approach:

The mmap() interpretation becomes very trivial since the blocks now appear in the new location as if by magic, while the former blocks are still available until you do the truncate().
There is no issue with allocated but unused blocks at the end of the file since you haven't changed the file size and the truncate() is already handling the issue
You have no issue with collapse extending to the end of the file since trucate() handles this issue.

With so many issues with the interface as proposed, and a very simple alternative, it's not clear to me why you'd do anything else.