What's the verdict: does it increase or decrease write amplification?
>>106460815I thought CoW was more efficient for blocks and stuff
>>106460815Copy on write on file systems is a super stupid and antiquated feature. When I plan my enterprise class systems, I chose replications and backup. In fact, the more copies I have the more I feel safe. I want replicas at the level of hard drive, location, and continent. Even at the level of filesystem, if a single file is kept twice identical I don’t mind, it costs me a fraction of the risk of losing the data.Even for the sole reason that makes copy on write meaningful, snapshotting backups, I make them over the ocean. Hardlinking and deleting before updating achieves the same
>>106460815>What's the verdict: does it increase or decrease write amplification?The answer is obvious, it increases write amplification unless you finely tune it which most CoW fs allow you to. Even then it'll never be as good as straight non-CoW.The reality is unless you're specifically abusing this there's no way you're going to hit the TBW anyway.
I thought "Copy on Write" was misleadingly named and more like a shamble of file edits that theoretically improves wear-levelling
>>106460815>Copy-on-Write and SSD'sYeah?>What's the verdictOld as hell concept.>does it increase or decrease write amplification?>the ratio of the amount of data written to the storage device to the amount of data that the host system intended to writeSo, if you updated a text file to swap an "a" with a "b," how much of the actual file needs to be written?Since SSDs can only erase entire blocks (which can be as large as 100+MB), and must do so before re-using that physical area for new data. Using CoW would reduce the total amount of data written to the SSD, but not impact block erasures like this in a significant way. This issue has to be managed by the OS, and take into consideration that pages (~4kb-16kb) are the smallest sized unit that can be written to. The physical SSD may be able to provide temporary (but power-loss surviving) storage to manage this.
>>106461312Sounds atrocious. Are you managing the system well?
>>106461430Funnily enough OP provided an image of CoW applied to system memory (RAM) rather than a filesystem. Mainly this is used for multi-threaded applications that work on the same data.
>>106460815https://www.youtube.com/watch?v=V7V3kmJDHTATake it from this balding freak. CoW kills SSDs
>>106461627>CoW kills SSDsIt depends on the implementation. What specifically is Copied? How much? The algorithm needs to take into consideration the limitations of the drive. You can't just say CoW/ZFS kills SSDs. That's preposterous.
>>106461701The video proves otherwise
>>106461627Maybe ZFS, but what about Btrfs?
>>106461719btrfs is also CoW and will have the same issue.
>>106461735But isn't Btrfs implemented better
>>106461744>Btrfs implemented betterIt has a far worse track record at keeping your data safe than zfs on any storage medium. At the end of the day it has the same issue as zfs. You need to finely tune it if you want to reduce write amplification. It's not magic that works automatically.
>>106461769>You need to finely tune it if you want to reduce write amplificationDon't distros like Fedora do this by default?
>>106461709>The video proves otherwiseNo. In the video he explicitly concludes that with configuration tuning he was able to minimize ZFS write amplification to be basically the same as ext4.You don't know what you're talking about.
>>106461719Watch the video from 11:20. He got the same write volume as ext4.
>>106461769>You need to finely tune it if you want to reduce write amplificationSomething which should be extremely easy to auto-detect and auto-configure.
>>106461773That's not how it works. btrfs doesn't magically adapt to your workload once your fs is created. If your workload is lots of very small writes across many blocks and you create your filesystem with a high block size you're going to have a bad time. Same goes for zfs datasets, you need to adjust the settings based off the workload expected.
>>106461521A journal could combine lots of little writes to one page though, whereas CoW has to copy and write all the pages.Of course the SSD firmware creators know that too, so they almost certainly use some kind of journaling internally and reverse engineer the CoW pattern into a hybrid journalling/CoW pattern.It's a fucking inefficient unpredictable clusterfuck. NAND should be dumb, all the smarts should be in the OS.
why not just use f2fs on ssd ?
>>106462326Probably because ext4 is just as good and you don't risk losing all your data over something as simple as a power reset.
luv me btrfsluv me snapper luv me cow'ate ext4'ate rsync'ate timeshift Not a Red Hat worker, just don't like 'em, simple as.
>>106464713but you don't 'ate xfs?
>>106462449i still don't understand how f2fs can be that fragile to power resets when it's used on battery powered devices
>>106466746Because it's a relatively new fs still and full of bugs?https://www.usenix.org/system/files/atc19-jaffer.pdf
>>106461312Ditto. I have a NAS with SHR for drive level backups, a giant Toshiba spinning rust for replication, and RAID 1 NVME system drives. I’m also considering a cloud replication service too.
>>106466978>>106461312Ok don't use btrfs on a server then. What about desktop use?
