Announcement

Collapse
No announcement yet.

The New NTFS Driver Looks Like It Will Finally Be Ready With Linux 5.15

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • binarybanana
    replied
    Originally posted by pipe13 View Post
    I'm thinking either LVM/ext4 or btrfs. Is there any (dis)advantage to putting btrfs under LVM? This isn't cast in concrete yet -- would I maybe be best off KIS and just use lvm/ext4? For simplicity I'll want to use the same configuration on the big slow sdb drive, and any other sdd's I might acquire.
    I have a LUKS+LVM+btrfs setup and as far as I'm concerned btrfs on top of LVM works fine. There isn't really any disadvantage to it. You have two ways to do snapshots and subvolumes, but I think both have different use cases. I use LVM volumes to gain flexibility with how I can make use of space that's *not* occupied by btrfs. I also have swap, an extra volume for VM storage and another for VM swap. Plus a bunch of smaller volumes here and there for other random stuff.

    btrfs subvolumes don't really help here. They're great for doing snapshots though. I also like the compression features. I basically get 15% more storage for free. Also checksums mean I know when bitrot happens. In the worst case (like if you mount the same FS twice, either during hibernation in another OS, or in a VM with passed through disk access) you might get an unmountable FS that the repair tools only make worse. What works well however is btrfs-restore, which can read corrupted btrfs volume and dumps all the files with complete folder structure somewhere else. Why the repair tools are to bad when the restore tool can get everything back is a mystery. But that really only is an issue if you do something retarded like I did. Usually it's rock solid, even after unexpected power loss.

    Leave a comment:


  • theriddick
    replied
    Originally posted by enigmaxg2 View Post
    So, we can finally say goodbye to the atrocious CPU overhead and slowness of nfts-3g?
    It will be good to see some benchmarks come 5.15. But in saying that the current FUSE NTFS driver can be made to perform a little better then its default configuration with the right mount options.

    Leave a comment:


  • enigmaxg2
    replied
    So, we can finally say goodbye to the atrocious CPU overhead and slowness of nfts-3g?

    Leave a comment:


  • CommunityMember
    replied
    Originally posted by kylew77 View Post
    Sad to see the code GPLv2 with all the *BSD projects wanting to avoid any new GPL encumbered code.
    TTBOMK, there is no equivalent to OIN for the *BSDs. With the great unknown in regards to IP and licensing for NTFS, Paragon is likely choosing the only safe path.

    Leave a comment:


  • CommunityMember
    replied
    Originally posted by kbios View Post
    I hope you have a robust backup system
    And test it regularly. A backup without testing is like a promise to take out the trash. Easily made, and likely not to work out exactly as some might hope.

    Leave a comment:


  • stargeizer
    replied
    Originally posted by arQon View Post

    No, it absolutely does not.

    Hopefully you have a good backup policy despite your confusion, right?

    Alternatively, can I interest you in this bridge I have for sale? :P
    It will protect for the 80%-90% of the cases when there's some problem with the write of files/metadata, at the cost of speed. Of course, it requires sane Hardware PC/Notebook configuration (E.g. Don't expect great protection in any system/OS if you have installed different manufacturer RAM modules, or use that cheap SATA cable, or that cheap power supply on your machine), but at least here, ext4 is less problematic than, let's say NTFS-3G/NTFS Windows/OpenZFS when dealing with errors. But as usual, YMMV, since hardware varies, and there's also the silicon lottery to consider.

    Leave a comment:


  • pipe13
    replied
    Okay. I've ordered the parts for a new build. First in ten years so I might be a bit stale. I'll need to pick some filesystems. The new machine will be 5950x and initially have a 2TB SDD plus 8TB rotating rust for backup and storage. I use rsnapshot for backup. Fedora is my daily driver. I'm open to suggestions, but I'm thinking
    /dev/sda:
    1MB grub2
    256MB UEFI fat16 or exFAT WHICH???
    2GB boot
    64GB ext4 Fedora
    64GB ext4 CentOS9 when released
    128GB linux swap
    1.74TB <rest>

    /dev/sdb:
    Backup, remote sensing images, and old project dirs I don't use much but don't want to lose.

    ...where <rest> is TBD Real Soon. My current system is a 2500k SNB. VMs work, but they don't work real well. So I multiboot a raft of distros that will go into VMs on the new build. On my current system <rest> is just a single ext4 partition where I place a shared /home and maybe a few other things. But the new system will be with me a while, and might do with something else. ext4 under lvm, btrfs, and xfs are the likely suspects, as they work well and are popular with the RedHats. NFS is a likely requirement, as I'll eventually need to install a Windows VM and share files. This link says it's easy https://graspingtech.com/mount-nfs-share-windows-10/
    ...but if any of you disagree I'd sure rather know now than later.

    I'm thinking either LVM/ext4 or btrfs. Is there any (dis)advantage to putting btrfs under LVM? This isn't cast in concrete yet -- would I maybe be best off KIS and just use lvm/ext4? For simplicity I'll want to use the same configuration on the big slow sdb drive, and any other sdd's I might acquire.

    I really need a refresher on btrfs and lvm. Please don't waste your life on it, but any quick suggestions will be appreciated. Thanks!

    Leave a comment:


  • arQon
    replied
    Originally posted by kylew77 View Post
    Sad to see the code GPLv2 with all the *BSD projects wanting to avoid any new GPL encumbered code. When I migrated some data on an external hard drive to FreeBSD 12.x a couple years back it was really hard because it was ExFat formatted. EXT4, NTFS, ExFAT- all are undersupported on OpenBSD and FreeBSD and I assume the other two big *BSDs as well.
    Do you perhaps see the connection there?

    I admit, for a long time I preferred BSD's license over the more restrictive GPL, but having seen abuses like Android etc for years now I've been forced to lean more strongly to GPL instead. (Not that it helped in Android's case anyway, but...)

    Leave a comment:


  • arQon
    replied
    Originally posted by kbios View Post
    The data=journal mode absolutely protects from data loss
    No, it absolutely does not.

    Hopefully you have a good backup policy despite your confusion, right?

    Alternatively, can I interest you in this bridge I have for sale? :P

    Leave a comment:


  • kylew77
    replied
    Sad to see the code GPLv2 with all the *BSD projects wanting to avoid any new GPL encumbered code. When I migrated some data on an external hard drive to FreeBSD 12.x a couple years back it was really hard because it was ExFat formatted. EXT4, NTFS, ExFAT- all are undersupported on OpenBSD and FreeBSD and I assume the other two big *BSDs as well. Whenever I post about the lack of a cross platform FS for the *BSDs people are quick to point out the Universal Disk format UDF but that lacks write support in some of the *BSDs. Even their own UFS/FFS implementations between say OpenBSD and FreeBSD aren't compatible and can result in corruption. It is hard to share files between Windows, Linux, and Open and FreeBSD.

    Leave a comment:

Working...
X