I thanked BTRFS because it informed me the error of data transfer or copy earlier after the first installing BTRFS. After my research, that was my defective RAM (9 months old) . Then I stopped using this RAM. memtest can not detect the error of this RAM because it is very rare.
Otherwise I would get several wrong data if I use EXT4 too long.
Useless, you don’t even notice defective storage when using non-CoW Filesystem e.g. EXT4.
I watched this video and am surprised that openZFS is the fastest CoW filesystem in the average.
Thank you, now makes more sense the reason why BTRFS has been more used from Linux distros, it “works out of the box”, so in this case i will wait kernel integration to consider openZFS in the future.
The conclusion is converging to:
use EXT4 when speed is important, because currently it is faster then BTRFS in average
use BTRFS when data protection is more important, but considering it’s not mature as ext4 is up to the user to take the risk.
So in my case would be:
New PC
SSD NVMe BTRFS for root and swap
SSD sata EXT4 dedicated for games
HD sata BTRFS personal data files shared with windows
Also, because I use a seperate NTFS data storage partition, I can freely uninstall and reinstall OS without backup my data. Thus you can see I make a clean install of Windows and Manjaro for at least every 6 months.
Sorry for this intermediate question: why is grub-btrfs installed even though NO btrfs filesystem was installed on the machine? At least it is the case with my ext4 system.
I also wonder why, but this package is just made to add scripts used when doing update-grub command when you have BTRFS file system. But I agree this shouldn’t be installed by default in a non BTRFS installation. I also agree this is off-topic and shouldn’t be in this thread.
as recommended here in case you are allocating a new partition to use in-between windows and linux, exfat seems to be the best option with least fuss. however if you are using existing NTFS partitions with data in them to avoid the hassle you can keep them as NTFS.
while ntfsfix is no chkdsk, it does basic repair. what most people forgo is that ntfsfix also marks every partition it checks as “dirty” irrespective of state of partition, to be cleared by an actual check with chkdsk later. ntfs3 is extra sensitive to NTFS status and does not mount “dirty” partitions. however you can avoid this using “-d” switch of ntfsfix.
i’ve resorted to using ntfs3 driver (mostly for less resource usage) with udisk2 so my NTFS partitions are auto-mounted on demand. i keep ntfs-3g driver as a backup driver to manually mount when i run into issues mounting with ntfs3.
Well I used it and it works, but it shouldn’t be used for critical data and in case of failures, you have to use Linux anyway. I also saw complete crashes, when using Win10 with this driver.
I think it is a bad idea to share a partition with this kind of custom driver. NTFS to me is the way to go for a share with Windows. NTFS is well supported now in kernel 5.15+ with the NTFS3 driver (which requires only proper mount options to work), and perfectly suitable to share data. Create the partition from Windows, and use it on both Windows and Linux without issue.
For ntfs-3g it is the same, while it is well tested and has less bugs However I still expect bugs in NTFS3 and therefore ntfs-3g is just the default. This btrfs driver is not custom, but rather a port to ReactOS, which as been adopted to real windows platforms.
If I have to choose, I would prefer an ext4 or btrfs driver for windows and not the way around. Windows drivers for both filesystems work, but they are far from being rock stable. At least for game data I would use these drivers.
To me it is by definition a custom driver, from the link you posted:
WinBtrfs is a Windows driver for the next-generation Linux filesystem Btrfs. A reimplementation from scratch, it contains no code from the Linux kernel
Also you can note I didn’t recommend using ntfs-3g implementation I specifically talked about NTFS3, which indeed may have bugs, but I disagree on your position.
I wouldn’t work on Linux file systems from Windows, and I would trust more the NTFS3 driver by a corporation that made working on file systems for almost 30 years its core business, than a driver rewritten from scratch on a GitHub project by one man. At the end of the day you do what you want but I don’t see how that makes more sense “the other way around”.
I wouldn’t use NTFS on Linux systems, either, if it were up to your argument. FAT12/16/32 and exFAT also not.
Ah yes, now comes the “expert argument”, which however has little weight. Just because a well-known company does it doesn’t automatically mean that they are better, especially since they mainly program software for Windows.
Anyway, if both Windows and Linux are to co-exist, then they must also fully support the respective file systems. Well, Paragon has a solution for this under Windows, of course: Linux File Systems for Windows | Paragon Software But, it is the same as ntfs-3g; it works in user space and not on the kernel space. I used and bought it, but it is not really stable and fast with lots of files and well, BTRFS is read-only. So this driver is not as good as it should be.
My bad and sorry for the confusion, I forgot to change the text and just copy and paste.
The 3. I’m going to change from NTFS to BTRFS as personal data, I will not keep dual boot anyumore. The number 4 that I removed from the list I will keep as back-up at NTFS, becasue in case I need, it can be read at windows too.
HD sata BTRFS personal data files
HD sata NTFS Back-up personal data files shared with windows (this drive is unplugged, I use it only when doing back-ups)
Come on, little weight? They indeed are expert in this domain. They make it their business. They officially added their code to the Kernel. This is a strong point.
i’m happy paragon managed to adapt its NTFS driver such that it could finally be part of the linux kernel (after many delays). from my use i only see a marginal performance increase compared to ntfs-3g, however efficiency-wise ntfs3 is way better (no more CPU/RAM hogging, at all).
however not all is smooth sailing with ntfs3. the moment you try to default to ntfs3 (ntfs-3g still being the default driver out-of-the-box, atleast in my setup) you run into ambiguity (somewhat mitigated) and feel there is some work still to be done. ntfs3 is supported by udisks2, but how it is implemented leaves little more to be desired. from the way i figured, there are issues arisen by adopting ntfs3 mounting mechanism to be a drop-in replacement for fuse+ntfs-3g system (specifically mounting options). you cannot expect everything to work right overnight just because there is a new kernel space driver. i’m sure there are decisions being made and work being done which will getover these soon.
for ntfs-3g, it seems its less finicky than ntfs3. i’ve had several instances where i could mount same NTFS partitions with ntfs-3g but not with ntfs3. ntfs3 will quit mounting for the slightest partition issues whilst ntfs-3g would mount it with no issues. (probably why you should be wary of using ntfs-3g in the first place).
For the ones that might ready this thread, I found the video below with nice explanation about ZFS that I will try to summarize below so people can have better conclusion.
ZFS is not recommended to single drive because the data will probably corrupt at any time, even if the user didn’t realize, it needs more then one driver to better work, due to how the system menage redundancies, so this sentence by itself eliminates my intention to use it.
ZFS compared to BTRFS and other file system has more overhead penalties and this is the reason it uses more memory and probably is slower (it has more features), and regarding the configuration you choose for your system it can became even worse.