5 ms·

Maybe flamebait, but here is my honest opinion, which I believe is aligned with the hacker ethos: maybe if you were using an open-source operating system you co

Maybe flamebait, but here is my honest opinion, which I believe is aligned with the hacker ethos: maybe if you were using an open-source operating system you could, with a little experience, write a simple tool that deletes a couple files without allocating new metadata. (Or more likely, somebody else would have been there before you and you could just use their tool.)

yjftsjthsd-h 3y ago
Does such a tool exist for BTRFS or ZFS?
- bjoli 3y ago
  I was in this situation with BTRFS, but it was simple to extend the partition with an old 2gb usb stick and the problem resolved itself.
  - yjftsjthsd-h 3y ago
    Sure, but that's orthogonal to open/closed source.
Kwpolska 3y ago
Most users on open-source operating systems can't code as well. And even if they could, this still requires knowledge or guesswork to find the trick for the deletion. Some people suggest truncation, and that's possible with a shell, but what would you do if it failed as well?
- qiqitori 3y ago
  I have an answer, but I'm not sure you'll find it particularly fulfilling because it is quite hypothetical. The average user just needs to be able to ask the question in a decent place. E.g., Hacker News or a fitting Stack Exchange site. Some developers not afraid of touching the kernel will see the question (or one like it), and if no workaround (e.g. truncation) is found to be acceptable, someone may decide to look into the kernel source to see if it's feasible at all. They may find a lower level function that deletes without writing metadata. Or they may find the function in the filesystem driver's source code where the metadata is written first, and if that was successful, the actual data is written. In the easiest case, you could create a copy of the function with the calls swapped, and a live CD with the modified driver could be created. (Course, this solution is quite unsafe, as writing the metadata could still fail for some other or related reason, so it's a bit of an emergency solution.) There are two other filesystems that were mentioned in the discussion here, btrfs and ZFS. ZFS solved the problem by reserving space, so creating such a tool isn't needed. (However, ZFS is not part of Linux, so I'm not too interested in digging into the details.) btrfs users apparently accept this as a fact-of-life, but have what they consider decent-enough workarounds, see e.g. https://www.reddit.com/r/btrfs/comments/ibjrpm/can_i_somehow_reserve_space_to_prevent_the_btrfs/ https://www.reddit.com/r/btrfs/comments/ibjrpm/can_i_somehow.... (I use neither ZFS nor btrfs; I prefer boring filesystems, thank you very much.)
Dylan16807 3y ago
> maybe if you were using an open-source operating system you could, with a little experience, write a simple tool that deletes a couple files without allocating new metadata For a filesystem where this happens, it would not be simple and it would require a lot of experience to get right. > Or more likely, somebody else would have been there before you and you could just use their tool. I don't think open-source makes such a tool much more likely to exist.

yjftsjthsd-h 3y ago

Does such a tool exist for BTRFS or ZFS?

bjoli 3y ago
I was in this situation with BTRFS, but it was simple to extend the partition with an old 2gb usb stick and the problem resolved itself.
- yjftsjthsd-h 3y ago
  Sure, but that's orthogonal to open/closed source.

Kwpolska 3y ago

Most users on open-source operating systems can't code as well. And even if they could, this still requires knowledge or guesswork to find the trick for the deletion. Some people suggest truncation, and that's possible with a shell, but what would you do if it failed as well?

qiqitori 3y ago
I have an answer, but I'm not sure you'll find it particularly fulfilling because it is quite hypothetical. The average user just needs to be able to ask the question in a decent place. E.g., Hacker News or a fitting Stack Exchange site. Some developers not afraid of touching the kernel will see the question (or one like it), and if no workaround (e.g. truncation) is found to be acceptable, someone may decide to look into the kernel source to see if it's feasible at all. They may find a lower level function that deletes without writing metadata. Or they may find the function in the filesystem driver's source code where the metadata is written first, and if that was successful, the actual data is written. In the easiest case, you could create a copy of the function with the calls swapped, and a live CD with the modified driver could be created. (Course, this solution is quite unsafe, as writing the metadata could still fail for some other or related reason, so it's a bit of an emergency solution.) There are two other filesystems that were mentioned in the discussion here, btrfs and ZFS. ZFS solved the problem by reserving space, so creating such a tool isn't needed. (However, ZFS is not part of Linux, so I'm not too interested in digging into the details.) btrfs users apparently accept this as a fact-of-life, but have what they consider decent-enough workarounds, see e.g. https://www.reddit.com/r/btrfs/comments/ibjrpm/can_i_somehow_reserve_space_to_prevent_the_btrfs/ https://www.reddit.com/r/btrfs/comments/ibjrpm/can_i_somehow.... (I use neither ZFS nor btrfs; I prefer boring filesystems, thank you very much.)

Dylan16807 3y ago

> maybe if you were using an open-source operating system you could, with a little experience, write a simple tool that deletes a couple files without allocating new metadata For a filesystem where this happens, it would not be simple and it would require a lot of experience to get right. > Or more likely, somebody else would have been there before you and you could just use their tool. I don't think open-source makes such a tool much more likely to exist.