Announcement

Collapse
No announcement yet.

LanyardFS: A New Linux File-System

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

  • #16
    mkfs.ext4 -O ^has_journal & noatime

    Originally posted by uid313 View Post
    Why not use ext4 with journal?
    I actually format the sticks in ext4 WITHOUT journal (-O ^has_journal) which is better than using ext2/3.

    noatime is also a must, and i use it everywhere. I don't care when was the last time i opened a file, those are unwanted writes.
    relatime only delays the writes, noatime is a must to avoid stupid writes when reading files.
    Last edited by Artemis3; 08-20-2012, 02:14 PM.

    Comment


    • #17
      Originally posted by DMJC View Post
      99% of portable devices need to operate with at least one Windows PC or a Macintosh. Until there's an IFS driver for windows and a proper Mac driver, any filesystem released for portable devices is a useless waste of devloper time. All 3 people that are exclusively Linux users are going to use this and everyone else is going to ignore it. If developers want to start pushing their technologies they have to aim for interop. Anything less just isn't acceptable anymore. Especially for low level stuff like Filesystems. We have OpenGL, OpenAL, SDL, and Fat32. Until you're ready to add your filesystem to that reasonably prestigious lineup. You won't get adoption. Linux already has ~50 filesystems most of which are useless outside of their niches due to lack of interop.
      i think you mean 1%, thereis a massive universe of portable/low power/specific devices out there outside your ipod and your digital cam and no one in its right mind is going to write a driver to access the low level infrastructure of a portable/industrial device to start with and this was not designed to replace your pendrive FS either but more for very restrained enviroments like arduino or another ULP arm microcontroller that only need to write small chunks of data before transmit[tcp/rs-232/usb/etc] saving as many cycles as possible, especially in many industrial sensors or servos when ext2/3/4 is like kill flie with a tomahawk missile.

      now on the pc/server market is true i don't see it useful in any way but for the industrial and ULP microcontroller can prove to be useful or at least used as base reference implementation for custom low cycle FS in this devices

      "Linux already has ~50 filesystems most of which are useless outside of their niches due to lack of interop" so?? i don't see the logic in interop at all since each of those fulfill a very different scenario and are not meant to be used for average joe's from the ground up and if you are referring to extX,xfs,btrfs, etc[the desktop/server grade FS] they work perfectly fine in linux, is apple and microsoft decision if they wanna provide support linux with their FS or allow a linux one used in their OS.

      and no microsoft has not help ntfs/fat/etc. outside windows either it was reversed[and i think they tried to sue linux for it]

      Comment


      • #18
        I find that transparent compression a la btrfs is good for flash drives as well as noatime. With transparent compression you read/write less data and the relative CPU time needed to compress/decompress is negligible, even if you use an expensive algorithm like LZMA.

        Comment


        • #19
          Originally posted by allquixotic View Post
          I find that transparent compression a la btrfs is good for flash drives as well as noatime. With transparent compression you read/write less data and the relative CPU time needed to compress/decompress is negligible, even if you use an expensive algorithm like LZMA.
          Wouldn't that still be a net negative for changing files?

          ie, change one word in a big text doc. Only that erase block changes.

          If the FS is compressed, that block and all blocks after it would change.

          Comment


          • #20
            *all blocks after it that have the file.

            Editing still broken yada yada.

            Comment


            • #21
              Originally posted by curaga View Post
              Wouldn't that still be a net negative for changing files?

              ie, change one word in a big text doc. Only that erase block changes.

              If the FS is compressed, that block and all blocks after it would change.
              For lots of little writes, yeah -- but also remember that there are fewer blocks in the file to begin with because it's compressed. The worst possible situation would be frequently changing files that don't compress well (or at all)... like if you were editing MP3s on your flash drive.

              It's actually more suitable for files that are frequently read but infrequently modified. Usually stuff in /usr of an operating system -- so if you're booting an OS off of a flash drive, you probably want to enable transparent compression for /, but not for /home. That way your boot time will be drastically reduced because you have to read less data from the slow flash cells and pass less data through the slow USB bus. But in /home you'll have lots of tiny files constantly being modified; GNOME config files; browser cache; and so on. For those, you're right that any change could affect more blocks than necessary and require a lot of rewrites... but I thought there were compression schemes that are "stable" in the sense that changing one block within the file doesn't change the entire file in a ripple effect? I remember reading that about maybe LZO or Speedy codec somewhere... but I doubt LZMA is stable because the focus is on compression ratio first.

              Comment


              • #22
                Wouldn't it be better to implement an IFS to extend FAT32 to allow files larger 4GB without changing the filesystem format? It would work similarly to how umsdos works. Call it SuperFAT or something. All files larger than 4GB would be split into multiple 4GB files and go into the SUPER.FAT directory in the root of the filesystem along with information for the IFS to make the split file appear as one large file in the filesystem hierarchy. You would even be able to retrieve the data without a SuperFAT IFS. All you would have to do is recombine the split file to another filesystem that supports files larger than 4GB. Simple and has some level of backward compatibility. I'd write up an IFS myself, but I'm not much C programmer.

                Comment

                Working...
                X