When and why to deprecate filesystems

Posted Mar 7, 2022 21:01 UTC (Mon) by Paf (subscriber, #91811)
In reply to: When and why to deprecate filesystems by calumapplepie
Parent article: When and why to deprecate filesystems

"but it also means checking other files to see if they're using those extents rather than just marking them as free."

No, it means checking the extent reference count, no need to know who's using it. It's not expensive. The other reasons you gave are real downsides, though.

But I do agree that EXT4 is not going to suddenly become a COW file system. For one thing, a COW file system is a different design point that is very far from globally superior to an extent based file system. It is different, with advantages and disadvantages.

It could *conceivably* gain some limited COW capabilities like I believe XFS has, where it can be done optionally for specific files.

When and why to deprecate filesystems

Posted Mar 8, 2022 6:16 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link] (1 responses)

The XFS thing is what I'm hoping to have eventually. I want just enough COW to be able to do cp --reflink=always and run rmlint.

When and why to deprecate filesystems

Posted Mar 16, 2022 3:14 UTC (Wed) by nevyn (guest, #33129) [Link]

Probably want to explicitly ask for reflink support, as the COW bits are implied and has some chance of being done.

When and why to deprecate filesystems

Posted Mar 20, 2022 6:50 UTC (Sun) by oldtomas (guest, #72579) [Link]

"No, it means checking the extent reference count"

Yes, but. If you look at the garbage collector community you soon realize that /maintaining/ those refcounts is expensive. It means one write access for each change in refcount.

That's why when GC performance starts to matter, most drop the first (naive) refcount implementation.

For file systems things won't be that different.