XFS With Linux 6.12 Adds New Ioctls To Exchange Contents Of Two Files

[phoronix]

Phoronix: XFS With Linux 6.12 Adds New Ioctls To Exchange Contents Of Two Files

The XFS file-system changes have been merged for the Linux 6.12 kernel and introduce new ioctls for being able to exchange the contents of two files...

https://www.phoronix.com/news/XFS-Linux-6.12

[intelfx]

"Using the same definition of file2 as struct xfs_exchange_range, commit the contents of file1 into file2 if file2 has the same inode number, mtime, and ctime as the arguments provided to the call. The old contents of file2 will be moved to file1."

So... a filesystem-level CAS primitive? Wow, that sounds fun.

[WileEPyote]

Awesome.
So now when can we expect support for shrinking volumes?

[uid313]

A bit cool.

I think in Linux all file I/O operations are synchronous. I heard something about io_uring but I heard it is insecure and nothing really uses it, so if you use a programming language such as C#, Java, Python or PHP then it won't use async for IO. Google have a OS called Fuchsia which use the Zircon kernel and it has asynchronous file I/O from the start.

I sometimes wonder why you cannot check for an attribute and open a file at the same time in one operation because if I check if a file is writable or is owned by a user then open it there is a small time between the permission check and the opening so that it might have changed.

Also some platforms such as Unix have a read_at and a write_at function where you can specify the offset to read from or write to but other platforms such as Windows don't have these functions so then you have to use fseek() instead before then call the read or write function, so it can be tricky to write portable code.

[dekernel]

Awesome.
So now when can we expect support for shrinking volumes?

In the 30+ years of using computers, I never once wanted or needed to shrink a volume. Now increasing a volume, that is another story because the volume of data never decreases. So other than playing around on a dev machine, when would you need to decrease the size of a volume?

[emansom]

...
when would you need to decrease the size of a volume?

When wanting to add a swap parition after installation for example.

[PuckPoltergeist]

Awesome.
So now when can we expect support for shrinking volumes?

When relocating the log is solved.

[skeevy420]

In the 30+ years of using computers, I never once wanted or needed to shrink a volume. Now increasing a volume, that is another story because the volume of data never decreases. So other than playing around on a dev machine, when would you need to decrease the size of a volume?

I have a bunch of times. Anyone who ever followed a distribution install guide from back in the day where separate partitions were suggested has potentially ran into this issue. I used to run into it back when I multi-booted with a single HDD, but that hasn't been an issue since I haven't had a PC without at least two disks in the past 20 years or so because of that...well, that and Windows occasionally overwriting the bootloader when it updates.

The last time I shrunk a volume was in 2016. It was an HDD that was 75/25 split between NTFS and OpenZFS. As I'd move more stuff from NTFS to OpenZFS I'd run out of space, shrink NTFS, expand OpenZFS, and copy some more files. While changing file systems when you only have the single large HDD is a bit of an edge case, it is something that people might need to do if they don't have access to a 2nd disk.

[shtripok]

In the 30+ years of using computers, I never once wanted or needed to shrink a volume. Now increasing a volume, that is another story because the volume of data never decreases. So other than playing around on a dev machine, when would you need to decrease the size of a volume?

To separate /home from root after some time.
To create separate volume for some project data, when that project grows up to be valuable.

[iustinp]

To separate /home from root after some time.
To create separate volume for some project data, when that project grows up to be valuable.

You have backups, right? Mount read-only, do last backup, delete, restore from backup.

All the home-use or SMB cases discussed here can easily be solved via backups, except it takes some time. But we're talking home or SMB, not 99.999% uptime, so meh. XFS still brings way more to the table than loses from not being able to shrink.