UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system) - Kernel

This is a discussion on UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system) - Kernel ; Artem Bityutskiy wrote: > I've renamed the thread because I do not like this flamish discussion > to me mixed with the technical one. > > Jörn Engel wrote: >> Shiny numbers! Performance has improved significantly in the last six ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

  1. UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Artem Bityutskiy wrote:

    > I've renamed the thread because I do not like this flamish discussion
    > to me mixed with the technical one.
    >
    > Jörn Engel wrote:
    >> Shiny numbers! Performance has improved significantly in the last six
    >> month. Still worth a closer look.

    > We'll re-run them. Does logfs support write-back? Does it support compression?


    For me, the motivators to wait for LogFS are mainly the facts that it
    can work on traditional block devices, and not only on pure flash:

    1. It works on normal block devices and it supports transparent compression

    Today, a 64 GB SSD/flash-based media costs ~about the same as a 1 TB
    hard disk. This makes flash very expensive to use; compression can
    compensate that cost a bit (will depend on the usage, of course).

    I believe there is no other Linux filesystem which can do transparent
    compression on block devices.


    2. It does wear-levelling also on normal block devices

    Although it doesn't sound normal to do wear-levelling twice (most
    flash-based block devices do wear-levelling on their own), I had a flash
    corruption after just ~one month of using RAID bitmap on a IDE-flash
    disk formatted with ext3. Apparently, device-level wear-levelling wasn't
    spreading updates of RAID bitmap file well enough.

    (...)

    > This basically means it is unfinished. Handling dynamic bad blocks is a *must*
    > if you are going to work on NAND, especially on MLC NAND which are not as
    > reliable as SLC.
    > I think you should bluntly say about this when you submit patches to prevent
    > people from starting using it in production.


    I too wouldn't use LogFS today in a production environment - it is still
    not feature complete and not widely tested.
    I wouldn't use btrfs or ext4 today for the very same reason.


    --
    Tomasz Chmielewski
    http://wpkg.org


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Tomasz Chmielewski wrote:
    > For me, the motivators to wait for LogFS are mainly the facts that it
    > can work on traditional block devices, and not only on pure flash:


    Sorry Thomasz, for me this makes zero sense. There are _much_ better file
    systems for block devices. UBIFS may work on top of a block device as
    well (just needs few hacks to make it possible) - it is not a problem
    at all, it is just _senseless_.

    JFFS2/UBIFS/LogFS is a separate _class_ of file-systems. The are designed
    for _flash_, which has completely different work model then block device.
    They are _native_ flash file systems.
    Here are more details: http://www.linux-mtd.infradead.org/f...l#L_mtd_vs_hdd

    The traditional FSes _cannot_ work on top of flash. The solution for this
    is using FTL, which emulates a block device on top of flash. It _hides_ the
    real device, and fakes a block device for you. And you can use traditional
    FSes on top of that fake block device.

    The whole _point_ of this separate class of FSes is because we believe
    we may do much _better_ job if we use flash _natively_, instead of using
    FTL. FTL is the place where you loose performance, reliability, and so on.

    And you are saying about using a native flash FS on top of a block device
    like an SD card. This is just not sane: SD card first emulates a block device
    for you, looses performance at this point, then you again emulate a flash
    on top of this, and suffer from this again.

    --
    Best Regards,
    Artem Bityutskiy (Артём Битюцкий)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    On Tue, 1 April 2008 11:45:56 +0300, Artem Bityutskiy wrote:
    > Tomasz Chmielewski wrote:
    > >For me, the motivators to wait for LogFS are mainly the facts that it
    > >can work on traditional block devices, and not only on pure flash:

    >
    > Sorry Thomasz, for me this makes zero sense. There are _much_ better file
    > systems for block devices. UBIFS may work on top of a block device as
    > well (just needs few hacks to make it possible) - it is not a problem
    > at all, it is just _senseless_.
    >
    > JFFS2/UBIFS/LogFS is a separate _class_ of file-systems. The are designed
    > for _flash_, which has completely different work model then block device.
    > They are _native_ flash file systems.
    > Here are more details:
    > http://www.linux-mtd.infradead.org/f...l#L_mtd_vs_hdd
    >
    > The traditional FSes _cannot_ work on top of flash. The solution for this
    > is using FTL, which emulates a block device on top of flash. It _hides_ the
    > real device, and fakes a block device for you. And you can use traditional
    > FSes on top of that fake block device.
    >
    > The whole _point_ of this separate class of FSes is because we believe
    > we may do much _better_ job if we use flash _natively_, instead of using
    > FTL. FTL is the place where you loose performance, reliability, and so on.
    >
    > And you are saying about using a native flash FS on top of a block device
    > like an SD card. This is just not sane: SD card first emulates a block
    > device
    > for you, looses performance at this point, then you again emulate a flash
    > on top of this, and suffer from this again.


    About a year ago I would have used roughly the same argument. But in
    the meanwhile I have accepted the fact that any piece of flash I'll use
    in a notebook in the next five years will likely use SATA or USB as a
    transport medium.

    Jörn

    --
    ....one more straw can't possibly matter...
    -- Kirby Bakken
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Jörn Engel wrote:
    > About a year ago I would have used roughly the same argument. But in
    > the meanwhile I have accepted the fact that any piece of flash I'll use
    > in a notebook in the next five years will likely use SATA or USB as a
    > transport medium.


    Well, Thomasz was talking not about the transport I believe. If you have a
    raw flash access via SATA or USB, then this is handled on the driver level
    and does not any require FS support. JFFS2 or UBIFS may also work with such a
    device, because it is just raw flash. But I know that you know that most of
    the FTL-enabled stuff does not give use raw flash access.

    --
    Best Regards,
    Artem Bityutskiy (Артём Битюцкий)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    On Tue, 1 April 2008 12:09:35 +0300, Artem Bityutskiy wrote:
    > Jörn Engel wrote:
    > >About a year ago I would have used roughly the same argument. But in
    > >the meanwhile I have accepted the fact that any piece of flash I'll use
    > >in a notebook in the next five years will likely use SATA or USB as a
    > >transport medium.

    >
    > Well, Thomasz was talking not about the transport I believe.


    When the day comes and I can actually use raw flash with a SATA or USB
    transport medium, I will be more careful and not imply that they all
    expose a block device interface. Today they do.

    [ With the exception of Alauda, which has a userbase of about 1 - me. ]

    Jörn

    --
    It does not matter how slowly you go, so long as you do not stop.
    -- Confucius
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Tomasz Chmielewski wrote:
    > Such as?


    ext3 for example.

    > Flash (also on block devices) is slow and expensive (when compared to
    > modern hard disks) and therefore compression is *very* useful here.

    Well, if you are ready to trade performance to compression, then well,
    go ahead :-) May be I used too strong wording, but I wanted to say then
    use raw flash then. But I'd also consider implementing compression support
    for a block based FS. Reiser4 claimed to have it for example.

    > Do you mean using hacks like block2mtd? It's hacky, and pretty hard to
    > boot a system this way (need to build own initramfs, with a static
    > block2mtd or loads of libraries - not something an average user would
    > like to do; no distro supports it; updating a kernel would be a pain etc.).

    Well, ok, it still sounds strange for me, but you may use JFFS2 and UBIFS
    with block2mtd as well if you really want to.

    > True.
    > Unfortunately, there is no way to access flash directly on flash-based
    > block devices (USB-sticks, IDE-flash disks, SSD disks etc.).

    Yeah, that's a pity :-(

    > Unfortunately, traditional filesystems were rather designed for rotating
    > media / cheap disks (no transparent compression; tend to accumulate
    > writes in one area of the disk - more on that - below).

    Sure.

    > Performance is only one factor in the equation. Other factors are: cost
    > and reliability.
    >
    > I speak from experience: flash-based block devices tend to have poor
    > wear-levelling (at least Transcend IDE-flash disks).
    > To reproduce:
    > - format a 2 GB Transcend IDE-flash disk with ext3
    > - write a small file (50-100 kB)
    > - update that file ~several hundred thousand times - as you finish,
    > IDE-flash disk will have 200-300 badblocks

    Yeah, that's bad. But if you have a bad FTL, surely there is not guarantee
    a flash FS will help? Isn't it better to use better hardware?

    We did some experiments with MMC cards and we were unable to wear them
    out with re-writing the same sectors again and again. This suggests there
    _is_ better FTL hardware then that USB stick you was using.

    Anyway, your original mail said Logfs can work with block devices. My answer -
    UBIFS too, but this is very strange to do this IMO. But OK, it might is not
    senseless, sorry for the wording. :-)

    --
    Best Regards,
    Artem Bityutskiy (Артём Битюцкий)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Artem Bityutskiy writes:

    > Tomasz Chmielewski wrote:
    > > For me, the motivators to wait for LogFS are mainly the facts that it
    > > can work on traditional block devices, and not only on pure flash:

    >
    > Sorry Thomasz, for me this makes zero sense. There are _much_ better file
    > systems for block devices.


    I think he refers to flash disks appearing as block devices, like
    usb sticks or similar.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Andi Kleen wrote:
    > Artem Bityutskiy writes:
    >
    >> Tomasz Chmielewski wrote:
    >>> For me, the motivators to wait for LogFS are mainly the facts that it
    >>> can work on traditional block devices, and not only on pure flash:

    >> Sorry Thomasz, for me this makes zero sense. There are _much_ better file
    >> systems for block devices.

    >
    > I think he refers to flash disks appearing as block devices, like
    > usb sticks or similar.


    Right, I also meant that in my opinion it makes more sense to use traditional
    file-systems like ext3 on USB-key/MMC and the like stuff (which I confusingly
    referred as "block devices"), or may be something more "heavy-weight" like
    XFS or JFS (never tried them, though).

    --
    Best Regards,
    Artem Bityutskiy (Артём Битюцкий)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Artem Bityutskiy wrote:
    > Andi Kleen wrote:
    >> Artem Bityutskiy writes:
    >>
    >>> Tomasz Chmielewski wrote:
    >>>> For me, the motivators to wait for LogFS are mainly the facts that it
    >>>> can work on traditional block devices, and not only on pure flash:
    >>> Sorry Thomasz, for me this makes zero sense. There are _much_ better
    >>> file
    >>> systems for block devices.

    >>
    >> I think he refers to flash disks appearing as block devices, like
    >> usb sticks or similar.

    >
    > Right, I also meant that in my opinion it makes more sense to use
    > traditional
    > file-systems like ext3 on USB-key/MMC and the like stuff (which I
    > confusingly
    > referred as "block devices"), or may be something more "heavy-weight" like
    > XFS or JFS (never tried them, though).
    >


    Well, even auto-levelling storage should benefit from a filesystem which
    minimizes the total number of flash sectors churned, which means doing
    as few writes as possible and to large, contiguous sections.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    On Tue, Apr 01, 2008 at 09:27:36AM -0700, H. Peter Anvin wrote:
    > Artem Bityutskiy wrote:
    > >Andi Kleen wrote:
    > >>Artem Bityutskiy writes:
    > >>
    > >>>Tomasz Chmielewski wrote:
    > >>>>For me, the motivators to wait for LogFS are mainly the facts that it
    > >>>>can work on traditional block devices, and not only on pure flash:
    > >>>Sorry Thomasz, for me this makes zero sense. There are _much_ better
    > >>>file
    > >>>systems for block devices.
    > >>
    > >>I think he refers to flash disks appearing as block devices, like
    > >>usb sticks or similar.

    > >
    > >Right, I also meant that in my opinion it makes more sense to use
    > >traditional
    > >file-systems like ext3 on USB-key/MMC and the like stuff (which I
    > >confusingly
    > >referred as "block devices"), or may be something more "heavy-weight" like
    > >XFS or JFS (never tried them, though).
    > >

    >
    > Well, even auto-levelling storage should benefit from a filesystem which
    > minimizes the total number of flash sectors churned, which means doing
    > as few writes as possible and to large, contiguous sections.


    Exactly. At exosec, we ship one appliance which writes statistics to a
    partition on a compactflash every 5 minutes. We preferred to go with JFFS2
    exactly because of this reason. We never had any problem proceeding this way.
    I'm not sure if it would have been the same with ext2 though.

    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Willy Tarreau wrote:
    >> Well, even auto-levelling storage should benefit from a filesystem which
    >> minimizes the total number of flash sectors churned, which means doing
    >> as few writes as possible and to large, contiguous sections.

    >
    > Exactly. At exosec, we ship one appliance which writes statistics to a
    > partition on a compactflash every 5 minutes. We preferred to go with JFFS2
    > exactly because of this reason. We never had any problem proceeding this way.
    > I'm not sure if it would have been the same with ext2 though.
    >


    Yes, as I agreed in a previous mail this may make sense in some cases.

    But in general it is not a good approach. Basically, it is wastage of resources.
    Indeed, first the firmware on MMC/SD/etc makes efforts to make flash look
    like a block device. It gives you in-place updates, but by cost of performance
    and reliability. Then you just drop this nice property, and use JFFS2, which
    assumes it has only out-of-place updates. But if this solves the task you have
    - fine!

    --
    Best Regards,
    Artem Bityutskiy (Артём Битюцкий)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    On Wed, Apr 02, 2008 at 07:47:25AM +0300, Artem Bityutskiy wrote:
    > Willy Tarreau wrote:
    > >>Well, even auto-levelling storage should benefit from a filesystem which
    > >>minimizes the total number of flash sectors churned, which means doing
    > >>as few writes as possible and to large, contiguous sections.

    > >
    > >Exactly. At exosec, we ship one appliance which writes statistics to a
    > >partition on a compactflash every 5 minutes. We preferred to go with JFFS2
    > >exactly because of this reason. We never had any problem proceeding this
    > >way.
    > >I'm not sure if it would have been the same with ext2 though.
    > >

    >
    > Yes, as I agreed in a previous mail this may make sense in some cases.
    >
    > But in general it is not a good approach. Basically, it is wastage of
    > resources.
    > Indeed, first the firmware on MMC/SD/etc makes efforts to make flash look
    > like a block device. It gives you in-place updates,


    One of the problem is that unless you crash-test your flash cards, you will
    never know if their wear-leveling algorithm is fine or not. And I suspect
    that nowadays, due to very large consumer demand, flash cards price drop
    at the cost of reliability. I think that most of those not flagged
    "industrial-grade" do absolutely zero wear-leveling, because they are sold
    to people using them in digital cameras, and they will never kill their
    device with such a usage.

    > but by cost of performance
    > and reliability. Then you just drop this nice property, and use JFFS2, which
    > assumes it has only out-of-place updates. But if this solves the task you
    > have


    I'm certainly not the only one with this requirement. A lot of embedded
    motherboards come with IDE compactflash connectors. This is very convenient,
    but if you need to keep informations between reboots, you have to write to
    the device anyway. If you need to do that very often, either you pray for
    the device to be very reliable, or you take all the chances on your side
    by adding your own wear-leveling "just in case".

    Cheers,
    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Willy Tarreau wrote:
    > One of the problem is that unless you crash-test your flash cards, you will
    > never know if their wear-leveling algorithm is fine or not. And I suspect
    > that nowadays, due to very large consumer demand, flash cards price drop
    > at the cost of reliability. I think that most of those not flagged
    > "industrial-grade" do absolutely zero wear-leveling, because they are sold
    > to people using them in digital cameras, and they will never kill their
    > device with such a usage.


    Sure, I know about this problem. My point was that in this case it is wiser
    to use bare flash and put JFFS2 on it, instead of using this black box
    MMC/etc and then put JFFS2 on it.

    > I'm certainly not the only one with this requirement. A lot of embedded
    > motherboards come with IDE compactflash connectors. This is very convenient,
    > but if you need to keep informations between reboots, you have to write to
    > the device anyway. If you need to do that very often, either you pray for
    > the device to be very reliable, or you take all the chances on your side
    > by adding your own wear-leveling "just in case".


    OK. Fair enough. Although stuff exists, but this does not necessarily mean
    this a good design :-)

    --
    Best Regards,
    Artem Bityutskiy (Артём Битюцкий)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Artem Bityutskiy schrieb:
    > Tomasz Chmielewski wrote:


    (...)

    >> Performance is only one factor in the equation. Other factors are:
    >> cost and reliability.
    >>
    >> I speak from experience: flash-based block devices tend to have poor
    >> wear-levelling (at least Transcend IDE-flash disks).
    >> To reproduce:
    >> - format a 2 GB Transcend IDE-flash disk with ext3
    >> - write a small file (50-100 kB)
    >> - update that file ~several hundred thousand times - as you finish,
    >> IDE-flash disk will have 200-300 badblocks

    > Yeah, that's bad. But if you have a bad FTL, surely there is not guarantee
    > a flash FS will help? Isn't it better to use better hardware?
    >
    > We did some experiments with MMC cards and we were unable to wear them
    > out with re-writing the same sectors again and again. This suggests there
    > _is_ better FTL hardware then that USB stick you was using.
    >
    > Anyway, your original mail said Logfs can work with block devices. My
    > answer -
    > UBIFS too, but this is very strange to do this IMO. But OK, it might is not
    > senseless, sorry for the wording. :-)


    I was thinking why my IDE-flash disk died so soon[1] and how efficient
    can an internal wear-levelling be in devices which hide its "flashiness"
    (USB-sticks, IDE-flash disks etc.).

    Internal wear-levelling mechanism doesn't have a clue about free space
    on the filesystem - it that case, how can it do any efficient
    wear-levelling?



    [1] Well, it didn't die, really. Once I removed the file which was
    showing I/O errors and did "dd if=/dev/zero of=bigfile", there are no
    badblocks anymore - probably remapped.



    --
    Tomasz Chmielewski
    http://wpkg.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    On Wed, 2 April 2008 16:17:25 +0200, Tomasz Chmielewski wrote:
    >
    > [1] Well, it didn't die, really. Once I removed the file which was
    > showing I/O errors and did "dd if=/dev/zero of=bigfile", there are no
    > badblocks anymore - probably remapped.


    Could have been soft errors. Heaven knows how those devices report
    uncorrectable errors, but claiming the block to be bad is a good guess.
    Once blocks with uncorrectable errors are rewritten (the physical
    blocks, not what the device reports), they are perfectly usable again.

    Jörn

    --
    They laughed at Galileo. They laughed at Copernicus. They laughed at
    Columbus. But remember, they also laughed at Bozo the Clown.
    -- unknown
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    On Wed, 9 April 2008 23:09:07 +0200, Pavel Machek wrote:
    >
    > I'd like compressed filesystem for maps and lingvistic data... but
    > will the flash flesystems have 'reasonable' performance when used on
    > harddrive?


    If someone implemented readpages(), that might be possible - depending
    on your definition of 'reasonable' and your workload.

    Writes will hit the disk roughly in order. When readahead requests a
    bunch of pages, there is some chance of them being adjacent and having
    the block layer combine most of the bios into a few large ones.

    The main drawbacks are:
    - No reservations. If data is written in random order or several
    writers chew away in parallel, write order will be fairly pessimal.
    - No readahead yet. Wouldn't be hard to do.
    - Garbage collection completely ignores fragmentation. If segments are
    needed and one contains a nice long extend from a single file, that
    data will be written elsewhere, often split between two segments.
    Rinse, repeat and fragmentation will increase over time.
    - File creation/deletion currently will cause disk heads to jump in
    triangles. This hurts write performance on most flash media as well,
    so it will get changed reasonably soon.

    All of those are solvable. Some will definitely be solved because the
    help performance on flash media as well. Other may or may not.

    Jörn

    --
    When people work hard for you for a pat on the back, you've got
    to give them that pat.
    -- Robert Heinlein
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: UBIFS vs Logfs (was [RFC PATCH] UBIFS - new flash file system)

    Hi!

    > For me, the motivators to wait for LogFS are mainly the
    > facts that it
    > can work on traditional block devices, and not only on
    > pure flash:
    >
    > 1. It works on normal block devices and it supports
    > transparent compression
    >
    > Today, a 64 GB SSD/flash-based media costs ~about the
    > same as a 1 TB
    > hard disk. This makes flash very expensive to use;
    > compression can
    > compensate that cost a bit (will depend on the usage, of
    > course).
    >
    > I believe there is no other Linux filesystem which can
    > do transparent
    > compression on block devices.


    I'd like compressed filesystem for maps and lingvistic data... but
    will the flash flesystems have 'reasonable' performance when used on
    harddrive?
    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread