Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: F2FS File-System Shows Hope, Runs Against Btrfs & EXT4

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,306

    Default F2FS File-System Shows Hope, Runs Against Btrfs & EXT4

    Phoronix: F2FS File-System Shows Hope, Runs Against Btrfs & EXT4

    Being released soon is the Linux 3.8 kernel and one of its many new features is the introduction of the F2FS file-system. The "Flash-Friendly File-System" was developed by Samsung and is showing promise as a new Linux file-system designed around the characteristics of flash-based storage devices. In this article are the first benchmarks of F2FS compared to Btrfs, EXT3, EXT4, XFS, JFS, and ReiserFS file-systems.

    http://www.phoronix.com/vr.php?view=18483

  2. #2
    Join Date
    Oct 2007
    Posts
    90

    Default

    What about Tux3?

  3. #3
    Join Date
    Feb 2012
    Posts
    70

    Default

    Not fsyncing data to the "disc" is OK-ish for me. Reason : It is developed primarily for flash storage.

  4. #4
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    861

    Default

    Quote Originally Posted by mayankleoboy1 View Post
    Not fsyncing data to the "disc" is OK-ish for me. Reason : It is developed primarily for flash storage.
    Another nice thing is that this filesystem will mostly be used on devices with a battery. In theory this means that it's less likely to experience a sudden power loss. At least, most phones shut themselves down when their battery gets dangerously low. This won't protect data integrity when the kernel crashes, or the user yanks the battery, but it's something to note.

  5. #5
    Join Date
    Oct 2012
    Posts
    273

    Default

    Quote Originally Posted by mayankleoboy1 View Post
    Not fsyncing data to the "disc" is OK-ish for me. Reason : It is developed primarily for flash storage.
    why should that be a reason???

  6. #6
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,859

    Default

    Quote Originally Posted by a user View Post
    why should that be a reason???
    Just guessing here, but probably because write times are so fast that its unlikely for the power to die (considering its on battery) at the exact moment something important is in the cache. Also constant fsyncs ruin flash medium lol

  7. #7
    Join Date
    Jun 2012
    Posts
    282

    Default

    Quote Originally Posted by a user View Post
    why should that be a reason???
    As far as I understand, it's log-structured so it (at least theoretically) could just revert incomplete writes and get some valid old state by just discarding incomplete logs. In fact, standard fsync() semantic is quite awkward and unnatural when it comes to log-structured/copy-on-write/similar designs where multiple versions of data present at the same time. However, APIs and software were designed in days where CoW-like designs were uncommon. So this semantic has been okay for filesystems used at that time.

    And you see, most of "classic" filesystems are only journaling metadata but not data. So while they ensure that metadata state is correct, they don't really care about actual data. So if you rewrite file and power is getting lost right at that moment, filesystem will be able to get correct metadata state by using journal so they describe some valid blocks. However actual file content could be half-old and half-new. You see, "classic" designs usually do not perform FULL journalling. Because it implies huge speed penalty as in classic designs they first have to write intent to journal and then actually commit it to data area. If all data included into journal and then into main area, they written twice and as the result, there is at least 2x penalty in write speed. As the result most filesystems resorted to only journaling metadata so at least you dont have to run fsck for hours to correct erroneous metadata. Some filesystems like EXT4 still include option to do full journalling. But full journalling mode is slow for mentioned reasons so almost nobody uses it. Some filesystems don't implemented full journalling at all as it's slow anyway.

    Then we come to CoW/log-structured designs. Some bright head(s) decided that let the whole storage area to be a journal. Then there is no dedicated data area - it's a huge journal instead. So no commits to data area. So no double writes and no write speed penalty while retaining all properties of full journalling mode. Upon write it does not overwrites old data but rather writes them to new place (hence "copy-on-write"). So in fact there is TWO versions of data appear. Old one, and new one. Old data state is constructed by just ignoring newly written fragment. New data state is constructed by taking it into account. So in fact there are multiple states could co-exist. That't also makes snapshots creation fast and easy - in fact all data and metadata are already here so it's just enough to declare it snapshot. Upon crash it's enough to discard incomplete writes and you have "old" state. Automatically. So either write completes and you have new state or it simply discarded. So it's also referred as "non-destructive write". Modern filesystems are often using this design due to mentioned advantages, even if they imply some complications as well (garbage collector needed, etc). Say btrfs of nilfs or zfs are good examples. And as far as I understand F2FS does something like that as well.

    As for me its highly debatable if log-structured design ignoring fsync() would cause more data loss than classic journal design which does not cares about rewrites of the file and actual data state after crash. Say, many file formats would become unreadable if they happen to be half-old and half-new. In fact, fsync as it currently used by apps would just slow-down CoW-based designs without any good reasons. In ideal world there should be some calls to mark "pre-transaction" state and "post-transaction" states for quite large "transactions". But it's not how posix file access api designed...

  8. #8
    Join Date
    May 2011
    Posts
    15

    Default

    Quote Originally Posted by 0xBADCODE;314645And you see, most of "classic" filesystems are [B
    only journaling metadata[/B] but not data. So while they ensure that metadata state is correct, they don't really care about actual data. So if you rewrite file and power is getting lost right at that moment, filesystem will be able to get correct metadata state by using journal so they describe some valid blocks. However actual file content could be half-old and half-new. You see, "classic" designs usually do not perform FULL journalling.
    I'm glad you said "usually"

    The first thing I do when setting up a filesystem is to set the mount options to full journalling - flash or spinning rust.

    You can set journalling to writeback when setting up a disk, but once you're using for real live data that's a kick in the pants waiting to happen. Yes it costs speed. I consider data integrity more important (and I use ZFS on machines which are physically capable of taking multiple drives) than having fast access to corrupted data.

    On a flash drive there's virtually no gain in delaying writes more than a few ms, so why do it?

  9. #9
    Join Date
    Sep 2011
    Posts
    155

    Default

    Quote Originally Posted by EmbraceUnity View Post
    What about Tux3?
    I'm guessing cause its not in the Kernel tree.

  10. #10
    Join Date
    Jul 2012
    Location
    SuperUserLand
    Posts
    528

    Default

    I have sdcards, flash pens, external hd's, etc etc


    they are all in either exfat or fat32

    so FUCK YES this needs to happen and happen fast


    I also question phoronix:


    WHY THE FUCK are you comparing f2fs to ext4 etc? and in a linux install? who the fuck cares


    here's an idea: HOW ABOUT A RELEVANT FUCKING TEST like comparing f2fs perfomance to exfat and fat32 in SD cards and USB pens ???

    y r people so stupid ffs

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •