The shrinking role of ETXTBSY

Posted Aug 19, 2021 16:37 UTC (Thu) by mbunkus (subscriber, #87248)
In reply to: The shrinking role of ETXTBSY by Sesse
Parent article: The shrinking role of ETXTBSY

You might not have enough space on the device for that, and checking whether or not that's the case beforehand is impossible to do reliably (what about file holes: are there any, does the FS support them; or simply that other processes might write to the same FS at the same time).

The shrinking role of ETXTBSY

Posted Aug 19, 2021 16:41 UTC (Thu) by Sesse (subscriber, #53779) [Link] (3 responses)

Sure, but that also goes when overwriting the file.

The shrinking role of ETXTBSY

Posted Aug 19, 2021 17:38 UTC (Thu) by mbunkus (subscriber, #87248) [Link] (2 responses)

I should have been clearer on what I mean. Of course I'm not talking about new_file being bigger than (old_file + free_before_copying). That wouldn't fit either way.

I'm talking about new_file being smaller than (old_file + free_before_copying) but being larger than free_before_copying. If you copy-to-temporary with atomic-rename you'll run out of space whereas directly opening the target file for writing will work.

Take this dummy 1MB file system with one 800KB file occupying it, trying to overwrite the 800KB file with a 400KB file:

[0 root@sweet-chili /home/mosu/tmp/mp] df .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop0 996 797 128 87% /home/mosu/tmp/mp
[0 root@sweet-chili /home/mosu/tmp/mp] ls -l
total 796
-rw-r--r-- 1 root root 800000 2021-08-19 19:30 800KB
[0 root@sweet-chili /home/mosu/tmp/mp] ls -l ../*KB
-rw-r--r-- 1 root root 400000 2021-08-19 19:30 ../400KB
-rw-r--r-- 1 root root 800000 2021-08-19 19:30 ../800KB
[0 root@sweet-chili /home/mosu/tmp/mp] cp ../400KB .
cp: error writing './400KB': No space left on device
[1 root@sweet-chili /home/mosu/tmp/mp] rm 400KB
[0 root@sweet-chili /home/mosu/tmp/mp] cp ../400KB 800KB
[0 root@sweet-chili /home/mosu/tmp/mp] ls -l
total 404
-rw-r--r-- 1 root root 400000 2021-08-19 19:33 800KB
[0 root@sweet-chili /home/mosu/tmp/mp]

rsync does the copy-to-temporary with atomic-rename, but it has always done so & is therefore fine. Of course it does have options to deal with low-space file systems the user can turn on, notably "--delete-before".

For cp it would be a huge change in semantics.

The shrinking role of ETXTBSY

Posted Aug 20, 2021 17:49 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

You can tell rsync to do the writing in place, though. This vastly speeds up some sync jobs, particularly databases.

The shrinking role of ETXTBSY

Posted Aug 20, 2021 18:19 UTC (Fri) by mbunkus (subscriber, #87248) [Link]

Yep, rsync wasn't the best additional example here, in fact efficient in-place updates is what rsync is most known for.

My main point was that such a change would change cp's semantics. I shouldn't have brought rsync up.