From: Martin <m_btrfs@ml1.co.uk>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs on low end and high end FLASH
Date: Wed, 02 May 2012 01:41:40 +0100 [thread overview]
Message-ID: <jnpvs5$pvi$1@dough.gmane.org> (raw)
In-Reply-To: <jnpr08$shq$1@dough.gmane.org>
On 02/05/12 00:18, Martin wrote:
> How well suited is btrfs to low-end and high-end FLASH devices?
>
>
> Paraphrasing from a thread elsewhere:
>
> FLASH can be categorised into two classes, which have extremely
> different characteristics:
>
> (a) the low-end (USB, SDHC, CF, cheap ATA SSD);
A good FYI detailing low-end FLASH devices is given on:
Flash memory card design
https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey
For those examples, it looks like write chunks of 32kBytes or more may
well be a good idea...
> and (b) the high-end (SAS, PCIe, NAS, expensive ATA SSD).
>
>
> My own experience is that the low end (a) can have erase blocks as large
> as 4MBytes or more and they are easily worn out to failure. I've no idea
> what their page sizes might be nor what boundaries their wear levelling
> (if any) operate on.
>
> Their normal mode of operation is to use a "FAT32" filesystem and to be
> filled up linearly with large files. I guess the more scattered layout
> of extN is non-too sympathetic to their normal operation.
>
>
> The high-end (b) may well have 4kByte pages or smaller but they will
> typically operate with multiple page chunks that are much larger, where
> 16kBytes appear to be the optimum performance size for the devices I've
> seen so far.
>
>
> How well does btrfs fit in with the features for those two categories?
Regards,
Martin
prev parent reply other threads:[~2012-05-02 0:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-01 23:18 btrfs on low end and high end FLASH Martin
2012-05-02 0:41 ` Martin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='jnpvs5$pvi$1@dough.gmane.org' \
--to=m_btrfs@ml1.co.uk \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.