Filesystem performance overheads? - Embedded

This is a discussion on Filesystem performance overheads? - Embedded ; Hi all, Is anyone aware of studies that have been done to measure the performance overheads that result from using a filesystem? We want to know the performance loss that we would suffer using a filesystem like FAT16 on a ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Filesystem performance overheads?

  1. Filesystem performance overheads?

    Hi all,

    Is anyone aware of studies that have been done to measure the
    performance overheads that result from using a filesystem? We want to
    know the performance loss that we would suffer using a filesystem like
    FAT16 on a ramdisk versus using the memory as it is (raw reads and
    writes to memory, without considering it as a ramdisk with a file
    system).

    As far as I understand the performance loss would be miniscule,
    especially compared to what the filesystem buys us in convenience. But,
    still I am looking for some hard facts to back up this claim.

    Thanks & regards,
    Sachin


  2. Re: Filesystem performance overheads?

    > Is anyone aware of studies that have been done to measure the
    > performance overheads that result from using a filesystem? We want to
    > know the performance loss that we would suffer using a filesystem like
    > FAT16 on a ramdisk versus using the memory as it is (raw reads and
    > writes to memory, without considering it as a ramdisk with a file
    > system).


    It may be "small" but not "miniscule". For every access you would have
    to do a context switch and the kernel would have to run just to read
    data, as opposed to just being able to read it with one instruction and
    no context switch.

    Jon
    ----
    Learn to program using Linux assembly language
    http://www.cafeshops.com/bartlettpublish.8640017

  3. Re: Filesystem performance overheads?

    In article <4283b402$1@news.tulsaconnect.com>, johnnyb@eskimo.com
    says...
    > > Is anyone aware of studies that have been done to measure the
    > > performance overheads that result from using a filesystem? We want to
    > > know the performance loss that we would suffer using a filesystem like
    > > FAT16 on a ramdisk versus using the memory as it is (raw reads and
    > > writes to memory, without considering it as a ramdisk with a file
    > > system).

    >
    > It may be "small" but not "miniscule". For every access you would have
    > to do a context switch and the kernel would have to run just to read
    > data, as opposed to just being able to read it with one instruction and
    > no context switch.


    FAT16 (and variants) require walking the FAT chain whenever it is
    necessary to append, truncate, or seek in a file. Depending on
    cluster size and file size, that can be quite significant, and result in
    quite noticeable delays. Additionally, depending on the implementation,
    it's necessary to only allow one process access to the FAT at a time, in
    order to prevent corruption.

    --Gene

  4. Re: Filesystem performance overheads?

    For another take on this topic, you might have a look at this article that
    compares a database in a ramdisk versus an in-memory database, both on Linux
    systems.

    In-Memory Database Systems

    Linux Journal, September 1, 2002

    http://www.linuxjournal.com/article.php?sid=6133



    Or the proprietary version:
    http://www.mcobject.com/downloads/memorybenchmark.pdf








    "Gene S. Berkowitz" wrote in message
    news:MPG.1cf093d3c25a235e9897dc@news.comcast.gigan ews.com...
    > In article <4283b402$1@news.tulsaconnect.com>, johnnyb@eskimo.com
    > says...
    >> > Is anyone aware of studies that have been done to measure the
    >> > performance overheads that result from using a filesystem? We want to
    >> > know the performance loss that we would suffer using a filesystem like
    >> > FAT16 on a ramdisk versus using the memory as it is (raw reads and
    >> > writes to memory, without considering it as a ramdisk with a file
    >> > system).

    >>
    >> It may be "small" but not "miniscule". For every access you would have
    >> to do a context switch and the kernel would have to run just to read
    >> data, as opposed to just being able to read it with one instruction and
    >> no context switch.

    >
    > FAT16 (and variants) require walking the FAT chain whenever it is
    > necessary to append, truncate, or seek in a file. Depending on
    > cluster size and file size, that can be quite significant, and result in
    > quite noticeable delays. Additionally, depending on the implementation,
    > it's necessary to only allow one process access to the FAT at a time, in
    > order to prevent corruption.
    >
    > --Gene




+ Reply to Thread