KDE Ending Out June With Many Bug Fixes, Finally Supporting Btrfs Copy-On-Write

[polarathene]

[QUOTE=fredvej;n1189693]How is that useful? If I want a hard link I make a hard link, if I want a copy of the data (e.g. for editing without changing the original) I copy the file. /QUOTE]

BTRFS is CoW though. If you're going to make a change to data, it creates a new copy of the changed data only. On a non-CoW filesystem, you'd overwrite your changes on the edited file, making it a destructive action. Why would you want to pointlessly copy data?

[geearf]

As far as I can tell, btrfs' Copy on Write makes a hard link instead of copying the data. How is that useful? If I want a hard link I make a hard link, if I want a copy of the data (e.g. for editing without changing the original) I copy the file. How does btrfs handle making an actual copy of a file, not a hard link?

It's a reflink not a hardlink, but yeah I don't understand why reflink should be the default either.

[starshipeleven]

Why is btrfs copy on write something a desktop environment has to support? what happens if it isn't supported?

it was explained poorly, CoW works regardless.
It's only about using reflinks aka making copies of a file that are in fact just links to the same thing, the application must do a specific request for the filesystem to do that, otherwise it will copy as normal.

[starshipeleven]

As far as I can tell, btrfs' Copy on Write makes a hard link instead of copying the data. How is that useful? If I want a hard link I make a hard link, if I want a copy of the data (e.g. for editing without changing the original) I copy the file. How does btrfs handle making an actual copy of a file, not a hard link?

a reflink is not the same thing, it's more similar to de-duplicating the file, both files share the same blocks on the disk as long as they are identical, and when you change something in it the filesystem will only write the different blocks, not the whole file, so you can have hundreds of copies of the same thing with minor modifications without wasting a ton of space.

You can disable reflinks when doing the copy operation (or use an application that isn't aware of btrfs supporting reflinks) and it will copy the file in the normal way.

[Zan Lynx]

Yeah, kinda baffling. You'd think this is something the file system driver would take care of behind the scenes.
Otherwise, btrfs should be advertised as "offering support for CoW".

Linux does not have a "copy_file" system call. The "cp" command does a series of read/write calls, or in some cases it mmaps the source and calls write on the entire thing.

So the file system driver cannot know that a copy is going on unless a special ioctl is used. Like this one for btrfs. Which actually is generic and supports any FS that can do a reflink, so it is not btrfs specific.

[starshipeleven]

So the file system driver cannot know that a copy is going on unless a special ioctl is used. Like this one for btrfs. Which actually is generic and supports any FS that can do a reflink, so it is not btrfs specific.

A well-known filesystem that supports reflinks is XFS, plus there are a few cluster filesystems that support reflinks too. In general if the filesystem can be deduplicated it probably supports reflinks. Apart from NTFS because MS reasons.

Boy the article title is so wrong...