Find the answer to your Linux question:
Results 1 to 6 of 6
Hi All, I am currently working on Ext2/3 filesystem analysis on SLC NAND Flash device. I have added code at driver level to note the erase and write count to ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jun 2010
    Posts
    7

    Ext2/3 Filesystem Analysis


    Hi All,
    I am currently working on Ext2/3 filesystem analysis on SLC NAND Flash device.

    I have added code at driver level to note the erase and write count to each sectors at NAND flash device.

    With test application doing read/write of 64MB file with a particular pattern, I have noted below results
    With Ext2:
    Filesystem block at Sector 0 is being updated more frequently at ratio of 4 to 4.5 times that of data block.
    Filesystem block(super block copies) are being updated at twice the frequency compared to data block.

    With Ext3:
    Filesystem block at Sector 0 is being updated more frequently at ratio of 5.5 to 6 times that of data block.
    Filesystem block(super block copies) are being updated at around 1.5times the frequency compared to data block.

    Has anyone come across this kind of behaviour with these filesystems on NAND Flash?
    Please comment on this results.
    Many thanks,
    Sandeep

  2. #2
    Linux Guru Lakshmipathi's Avatar
    Join Date
    Sep 2006
    Location
    3rd rock from sun - Often seen near moon
    Posts
    1,769

    Exclamation

    ext2 + journal = ext3.
    Performance between ext2 and ext3 mostly depends on journal type ! Check you journal mode -is writeback/ordered or journal.

    writeback mode is the fastest with ext3 though unexpected reboot might corrupt data.
    First they ignore you,Then they laugh at you,Then they fight with you,Then you win. - M.K.Gandhi
    -----
    FOSS India Award winning ext3fs Undelete tool www.giis.co.in. Online Linux Terminal http://www.webminal.org

  3. #3
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    1. Don't use journaling file systems on flash.
    2. Make sure that it is mounted without the sync option as that will greatly shorten the lifecycle of a flash device.

    With the async (vs sync) option enabled, writes to the are cached and physically written at infrequent intervals, so even if you "see" 4-5 block updates in a given short period of time, it is likely that only 1 physical write has actually been done, especially if it is the same block that is being written (most common).

    Note that by default, automounted USB drives are mounted with the sync option (needed for hot unplugging). This is VERY BAD for thumb drives and SD cards in a card reader. That default behavior may be changable, but usually you need to remount the device in order to turn sync off. As a result, you then need to run the system 'sync' command before unmounting the drive, otherwise you will lose data and/or corrupt the drive.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  4. $spacer_open
    $spacer_close
  5. #4
    Just Joined!
    Join Date
    Jun 2010
    Posts
    7
    Thanks for your reply. I am doing a manual mount of flash. I have checked it and I have not used the sync option.
    Every physical write to the device is done with 30sec interval and whenever dirty pages crosses 10% of active memory limit is crossed, which we have observed.

    I have also tried with O_SYNC flag in my test application then there were more frequent physical writes compared to without this flag.

    With this results Ext2/Ext3 will worn out the flash device soon.

  6. #5
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    Well, the O_SYNC option will tell the driver to physically write the data to disc immediately, overcoming the intent of async (no sync) mounts, as you have found. In reality, flash file systems are supposed to migrate data from block to block in some intelligent fashion in order to balance the number of writes to the device. I'm personally not sure that this is effectively done in reality as yet. I try to use flash devices for read-mostly operations. You can also set the time-to-check on such devices to a number of mounts that will help to maximize their lifetime. This means that fsck -c (bad_block check) will be done more frequently than on rotating media.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  7. #6
    Just Joined!
    Join Date
    Jun 2010
    Posts
    7
    I should try with flash based filesystems with wear-levelling. This will have uniform writes throught the device.
    Thankyou

Posting Permissions

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