Find the answer to your Linux question:
Results 1 to 8 of 8
Hi ALL, I am currently working on Ext2 file-system on SLC NAND Flash device. I have added code which increments the erase/write count at sector level on NAND Flash device. ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jun 2010
    Posts
    7

    Ext2 Filesystem


    Hi ALL,

    I am currently working on Ext2 file-system on SLC NAND Flash device. I have added code which increments the erase/write count at sector level on NAND Flash device. So when ever there is a write or erase then this is increment the respective erase_count array and write count array respectively.

    I have created 3 test applications with below algorithm with different write/read sizes:

    #define MAX_COUNT 50
    Counter =0;
    Loop1:mount();
    Write_all();//open file, write data to NAND, close.
    Umount();
    Mount();
    Read_all();//open a file, read data from NAND, close.
    Umount();
    While(counter++ < MAX_COUNT) Loop1;

    1) testAP1-25KB write/read- Loop for 256 times to write 64MB file
    2) testAP2-1MB write/read-Loop for 64 times to write 64MB file
    3) testAp3-2MB write/read-Loop for 32 times to write 64MB file

    Below is erase/write count for Filesystem data at Sector 0:
    with testAP1: erase/write count =240
    testAP2: erase/write count=203
    testAP3:erase/write count=250


    Can any one please tell me having different write/read sizes in Test application will have any affect on the Filesystem block updates?
    What is the pattern/logic behind this?
    For this kind of behaviour where do I have to look in?

    Any suggestion would be appreciated.

    Many Thanks,
    Sandeep Yedire

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
    Posts
    11,173
    Has the device been mounted with, or without, the sync option?
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Jun 2010
    Posts
    7
    The device is mounted without sync option.

  4. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
    Posts
    11,173
    Are you sure that this variable is incremented on a physical write, or is it just incremented when the kernel gets a write command?
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  5. #5
    Just Joined!
    Join Date
    Jun 2010
    Posts
    7
    Yes I am sure, I have added increment count code in "./drivers/mtd/nand/".

  6. #6
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
    Posts
    11,173
    That is, when the physical block is actually re-written?
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  7. #7
    Just Joined!
    Join Date
    Jun 2010
    Posts
    7
    This based on PDflush deamon. This is based on 30sec max limit and Dirty pages > 10% active memory.
    Then physical block is being erased and updated with new data. Please not this ratio we are noticing for filesystem block at sector 0.

  8. #8
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
    Posts
    11,173
    Well, to get back to your original questions
    1. Can any one please tell me having different write/read sizes in Test application will have any affect on the Filesystem block updates?
    2. What is the pattern/logic behind this?
    3. For this kind of behaviour where do I have to look in?
    Answers:
    1. You will need to do some experimentation here to tell unless you can determine the answer from source code analysis.
    2. Don't know.
    3. Don't know.

    Helpful (not!) I know. Sorry, but I think you are ahead of me on analyzing this behavior.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

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