No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    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.


    • #32
      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.


      • #33
        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.


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


          • #35
            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.


            • #36
              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.


              • #37
                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.
                Ha. They can wish for whatever they want, why would Linux ecosystem bow to it?

                Say no to cuck licenses.


                • #38
                  Good news.

                  Will they do the same to their HFS+ implementation?

                  Maybe they will focus on APFS and release a ReFS implementation to get profit from it.

                  Anyway, they are expanding their market to forense computing.


                  • #39
                    Originally posted by Old Grouch View Post
                    exFAT is lousy for file archiving.

                    The problem is that ext(x) filesystems allow any character in a filename except for NULL and forward slash, which is a superset of the allowed characters in the exFAT definition:

                    For example: Asterisk; Less-than sign; Greater-than sign; Colon; Question mark; Vertical bar; and Back slash are not allowed in exFAT filenames (plus sundry control codes)

                    I've been caught out by this and had to rename a non-trivial number of files.

                    Similar restrictions apply to NTFS: - note that if NTFS uses the POSIX namespace any Unicode character except / and Null are is allowed. Note that the POSIX standard for portable filenames is considerably more restrictive.

                    Non-Microsoft drivers can put non-standard characters in filenames used in exFAT, but obviously this will generate undefined behaviour if accessed by a Microsoft driver, or one written to abide by the Microsoft specification.

                    I'm not going to hold up the relatively liberal approach of many Linux filesystems towards filename standards as being perfect. It is subject to well argued criticisms:

                    I'm still looking for a good cross-platform approach for file archiving. exFAT isn't the solution, and neither, unfortunately, is UDF (in any of its revisions), which is a shame.
                    I don't understand your point. Who or what makes you create files with "bad" characters in Linux? In my 30+ years of using PCs I've never had such troubles and never had the need to create files containing them. Lastly you can use sed, tr, awk to remove them if you like.


                    • #40
                      Originally posted by kbios View Post

                      The data=journal mode absolutely protects from data loss
                      It's 1) not default 2) it severely degrades performance 3) it increases fragmentation 4) it breaks some applications 5) It relies on your HW actually physically writing data out which is not guaranteed on consumer devices 6) I don't know anyone who uses it.

                      data=journal        All data are committed into the journal prior to being
                                  written into the main file system.  Enabling
                                  this mode will disable delayed allocation and
                                  O_DIRECT support.
                      You used a non-standard, rarely if ever used mode of journalling to counter my statement which renders your argument 100% invalid. Lastly I'm not even sure other journaled filesystems (e.g. XFS, JFS, Reiser) have this mode of operation.
                      Last edited by birdie; 02 August 2021, 07:01 AM.