Originally posted by curfew
View Post
Announcement
Collapse
No announcement yet.
Btrfs To Ship Multiple Performance Improvements In The Next Linux Kernel
Collapse
X
-
Originally posted by ssokolow View Post
I don't see how that could be accomplished without some kind of heuristic (ie. fallible) algorithm to guess at which files should and shouldn't be COWed.
Comment
-
Originally posted by curfew View PostThat's just retarded. Obviously there's no sense patching every single app that works with files to support a filesystem-level feature. It has to be a system service at a bare minimum if it cannot be built into the kernel.Last edited by Spazturtle; 23 October 2018, 06:16 AM.
- Likes 2
Comment
-
Originally posted by Spazturtle View Post
Not every app no, only ones that don't work well with COW. Only the application itself can know if it doesn't work well with COW, and only the application knows if it is safe to disable COW.
i wonder how APFS or ReFS does it
Comment
-
Originally posted by aht0 View Post
(2)Bunch of random incidents aided Linux equally or more than it's license. Linux took off in popularity when FreeBSD was implementing SMP and did at first shitty job. Then FreeBSD's users (it was used far more than Linux back then) migrated to Linux because it happened to be ready and accessible alternative (no OpenSolaris yet). Later times, additional factors aiding Linux were Oracle closing OpenSolaris after buying Sun and Google opting to use Linux kernel for it's new embedded OS Android. Without all of it, FreeBSD or OpenSolaris could easily be in the same position Linux has nowadays. Just mostly luck IMHO.
Where GPL in fact aided and served it's purpose was with Linksys court case - suddenly people could have access to sources for their routers - would not have been possible with BSD license.
Also, define success - Linux has a few percents market on desktop and still less far smaller market share in servers than Windows, except for web servers where it indeed rules the roost.
Copyleft is free-as-in-freedom, BSD/MIT/Apache is free-as-in-labor. And of course today companies are violating the terms of the GPL or using firmware and associated tricks to avoid releasing their code while still using Linux.
And Android explains why Linux is popular as the kernel on mobile operating systems. But even without Android, Linux conquered the server space.
- Likes 1
Comment
-
Originally posted by curfew View PostCongratulations! You're the third guy to answer and completely fail to understand the meaning of AUTOMATIC. Automation is the complete opposite of having to manage everything by hand. OP did not ask how to disable COW, he asked how to make it automatic. Implying he already knew how to do it manually.
Anyway , doing this automatic has to be done on the application level. And even then it is sort of "against" what the user expect of his/her/it's? filesystem.
The best "automatic" method is to create a separate subvolume, set that nocow and store your things in there. Ergo , a isolated part of the filesystem having nocow attribute set. On the other hand you *might* want to consider other filesystems for your use case , but then again you loose the flexibility of BTRFS anyway. Or another option is to enable the autodefrag option that sort of does the trick for some stuff.
http://www.dirtcellar.net
- Likes 2
Comment
-
Originally posted by nranger View PostNot sure what you mean by "checksums for parity against bitrot"? Btrfs has had checksumming for reliable data and metadata for years now.Originally posted by pal666 View Postparity was not checksummed in the past
The only advantage having a parity checksummed is the speed to detect a possible corruption. However, again, the parity checksummed is not needed from a reliability point of view.
Comment
-
kreijack lets think about this scenario. Raid 6, 5 Disks and one Disk failed. Parity on one disk is invalid. How does btrfs fix this problem now? How does it know which parity is invalid? Does the restore check it that the file was invalid with parity A and test again with parity B?
This is one of my concerns.
Comment
-
Originally posted by kaprikawn View PostThis is great and all, but I don't think most desktop users notice much difference in filesystems, I certainly don't. The difference between a HDD and an SSD is night and day, but once you've made that leap I don't think there's much in it. I recently went from a SATA 3 SSD to an NVME m.2 drive for reasons unrelated to performance, I didn't notice anything. I use BTRFS, I doubt I'd notice any difference if I went with EXT4, or whatever the performance leader is.
Still, that's just my use case, I'm sure under different workloads, especially in the server space, this is particularly useful. And it's nice that it's getting development attention.
Comment
Comment