Tuning for Compact Flash

Tuning for Compact Flash

[Christer Weinigel]

Hi all,

I have a Thinkpad X40 that I'd like to replace the Hitachi hard drive 
on.  The drive is 1"8 with a normal 2"5 PATA disk connector on the side 
and such disks are not manufactured any more, so I went out and bought a 
Compact Flash adapter and a Transcend 133X 32 GByte Compact Flash.

I installed Fedora 9 on the Compact Flash, with a small boot partition 
and then one large encrypted LVM partition where I put the swap 
partition and an ext3 file system.  This turned out to be bog slow, 
write speed to the ext3 file system seem to be about 1MByte/s which is 
just horrible.  Since Transcend claims 45MByte/s read bandwidth and 
16MByte/s write bandwidth, this seems much too low.

So, I did some simple tests to see how the compact flash behaves.  To 
measure write speed i did the following for different block sizes:

     dd oflag=direct if=/dev/zero of=/dev/sdd1 bs=$bs

and to measure read speed I did the following:

     dd iflag=direct if=/dev/sdd1 of=/dev/null bs=$bs

The results are:

                 Transcend Flash         Hitachi Hard Drive
Block Size      Write   Read            Write   Read
4k              2.2     14.4            14.2    20.1
16k             10.8    23.2            15.7    20.5
32k             15.6    31.2            15.7    20.5
64k             17.2    37.1            15.7    20.5
128k            17.8    44.5            15.8    20.5
1M              18.0    45.8            18.0    20.5
16M             17.8    46.0            20.5    20.5

It seems that Transcend were actually a bit conservative, the max read 
and write speeds actually exceed their claims, but as transfer size goes 
down, performance suffers.  (I ought to perform another test with 
non-transfer-size aligned transfers to see if that makes a difference, 
that could tell me some more about how the flash behaves internally.)

So, is there any file system for Linux that would perform better than 
ext3 on a device like this?  I need a file system with Posix semantics 
so that I can use it as my root file system, and it would be nice with a 
file system with some kind of journalling so that if the laptop powers 
off unexpectedly I don't have to run fsck.  Or is there any tuning of 
kernel parameters I can do to make ext3 + lvm + crypto run faster?

Has anyone looked at writing a file system especially targeted for this 
kind of flash devices?  The same issues I have with this compact flash 
ought to show up with other flash devices such as USB drives (some web 
page mentioned that the Transcend flash uses a Silicon Motion flash 
controller; another Silicon Motion flash controller is used in a lot of 
USB drivers so probably behaves similarly).

For the moment, I've put back the Hitachi hard drive in my laptop, but 
it is starting to become a bit noisy, so I'm afraid that it will fail 
soon and I'll have to switch to the flash drive despite its performance 
problems.  But for now I can play around with the flash drive and try 
different things on it.

   /Christer

Re: Tuning for Compact Flash

[jim owens]

Christer Weinigel wrote:
> 
> I have a Thinkpad X40 that I'd like to replace the Hitachi hard drive 
> on.  The drive is 1"8 with a normal 2"5 PATA disk connector on the side 
> and such disks are not manufactured any more, so I went out and bought a 
> Compact Flash adapter and a Transcend 133X 32 GByte Compact Flash.
> 
> I installed Fedora 9 on the Compact Flash, with a small boot partition 
> and then one large encrypted LVM partition where I put the swap 
> partition and an ext3 file system.  This turned out to be bog slow, 
> write speed to the ext3 file system seem to be about 1MByte/s which is 
> just horrible.  Since Transcend claims 45MByte/s read bandwidth and 
> 16MByte/s write bandwidth, this seems much too low.

CF is not an SSD.  A CF is designed and spec'd to store large images.
Neither CF nor USB thumb drives are intended as a primary system
hard drive.  They work great for transferring data between machines
but no filesystem or tuning will make them perform with the same
characteristics you expect of your primary hard drive.

jim

Re: Tuning for Compact Flash

[Artem Bityutskiy]

jim owens wrote:
> Christer Weinigel wrote:
>>
>> I have a Thinkpad X40 that I'd like to replace the Hitachi hard drive 
>> on.  The drive is 1"8 with a normal 2"5 PATA disk connector on the 
>> side and such disks are not manufactured any more, so I went out and 
>> bought a Compact Flash adapter and a Transcend 133X 32 GByte Compact 
>> Flash.
>>
>> I installed Fedora 9 on the Compact Flash, with a small boot partition 
>> and then one large encrypted LVM partition where I put the swap 
>> partition and an ext3 file system.  This turned out to be bog slow, 
>> write speed to the ext3 file system seem to be about 1MByte/s which is 
>> just horrible.  Since Transcend claims 45MByte/s read bandwidth and 
>> 16MByte/s write bandwidth, this seems much too low.
> 
> CF is not an SSD.  A CF is designed and spec'd to store large images.
> Neither CF nor USB thumb drives are intended as a primary system
> hard drive.  They work great for transferring data between machines
> but no filesystem or tuning will make them perform with the same
> characteristics you expect of your primary hard drive.

And I won't be surprised if they are optimized for FAT. Many SD cards
are - the first N sectors are often faster there, and in case of large
cards they may be mapped to SLC NAND, while the rest is mapped
to MLC NAND. I may suspect that CF may do something similar.

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

Re: Tuning for Compact Flash

[Christer Weinigel]

jim owens wrote:
> Christer Weinigel wrote:
>> I installed Fedora 9 on the Compact Flash, with a small boot partition 
>> and then one large encrypted LVM partition where I put the swap 
>> partition and an ext3 file system.  This turned out to be bog slow, 
>> write speed to the ext3 file system seem to be about 1MByte/s which is 
>> just horrible.  Since Transcend claims 45MByte/s read bandwidth and 
>> 16MByte/s write bandwidth, this seems much too low.
> 
> CF is not an SSD.  A CF is designed and spec'd to store large images.
> Neither CF nor USB thumb drives are intended as a primary system
> hard drive.  They work great for transferring data between machines
> but no filesystem or tuning will make them perform with the same
> characteristics you expect of your primary hard drive.

Of course it won't behave like a hard drive, but it would be nice if 
there was a file system with performance that didn't suck as badly on a 
compact flash.  Plain NAND flash is nothing like a hard drive either, 
but with a file system designed for the peculiarities of NAND flash, it 
does behave decently.

And it seems that the Silicon Motion SM223 controller used for Transcend 
Compact flash is the same that is used in some models of the Asus EEE 
and in a Transcend SSD, so in this case a CF is a SSD.

Anyway, I think I'll write a couple of more test programs to explore the 
performance characteristics of my particular flash device, see how 
alignment and accesses to different areas on the flash behave (since 
Artem mentioned that they may be optimised for FAT).

But I was hoping that someone else had already done this.  I can't be 
the only person with a laptop where a SSD won't fit and who wants to run 
Linux off a common of the shelf flash disk.

   /Christer

Re: Tuning for Compact Flash

[Martin K. Petersen]

>>>>> "Christer" == Christer Weinigel <christer@weinigel.se> writes:

Christer> Of course it won't behave like a hard drive, but it would be
Christer> nice if there was a file system with performance that didn't
Christer> suck as badly on a compact flash.

Well, you are limited by the capabilities of the FTL.  And as far as
CF goes the FTL is usually pretty braindead.

Making sure things are properly aligned really helps on "real" SSDs as
well as 4KB hw sector drives.  I'm working on some code that exposes
these parameters so we can perform that alignment when creating
filesystems.

But as far as CF is concerned I have tested many and not found a
single one that is suitable for a regular (random) filesystem write
workload.  To the extent that for embedded devices I ended up putting
a root filesystem tarball on the CF and unpacking it into ramfs during
boot.

And just to give you an idea: I'm getting two orders of magnitude less
random write ops on a (high-performance) CF than on a flash SSD from
the same vendor.  In both cases with I/O aligned to the flash page
boundary.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Tuning for Compact Flash

[Christer Weinigel]

Martin K. Petersen wrote:

>>>>>> "Christer" == Christer Weinigel <christer@weinigel.se> writes:
> 
> Christer> Of course it won't behave like a hard drive, but it would be
> Christer> nice if there was a file system with performance that didn't
> Christer> suck as badly on a compact flash.
> 
> Well, you are limited by the capabilities of the FTL.  And as far as
> CF goes the FTL is usually pretty braindead.


Yeah, I wish some flash manufacturer would do the right thing and just 
stick some NAND chips and some PCI/PCIe glue on a CardBus/ExpressCard. 
Something that allows a Linux driver to talk directly to the flash chips 
and then a simple DMA engine to do bus mastering block transfers to and 
from memory.  We could then run yaffs or whatever we wanted on it with 
no translation layers at all in between.

> But as far as CF is concerned I have tested many and not found a
> single one that is suitable for a regular (random) filesystem write
> workload.  To the extent that for embedded devices I ended up putting
> a root filesystem tarball on the CF and unpacking it into ramfs during
> boot.
> 
> And just to give you an idea: I'm getting two orders of magnitude less
> random write ops on a (high-performance) CF than on a flash SSD from
> the same vendor.  In both cases with I/O aligned to the flash page
> boundary.

That sounds just horrid.  Oh well, I won't have much choice when my hard 
drive dies, drives in this form factor are not manufactured any more and 
the only thing that will fit into the slot is a Compact Flash card or 
maybe with some hacking a USB drive.  :-)

  /Christer

Re: Tuning for Compact Flash

[Chuck Lever]

On Sep 29, 2008, at Sep 29, 2008, 7:11 PM, Christer Weinigel wrote:
> Martin K. Petersen wrote:
>
>>>>>>> "Christer" == Christer Weinigel <christer@weinigel.se> writes:
>> Christer> Of course it won't behave like a hard drive, but it would  
>> be
>> Christer> nice if there was a file system with performance that  
>> didn't
>> Christer> suck as badly on a compact flash.
>> Well, you are limited by the capabilities of the FTL.  And as far as
>> CF goes the FTL is usually pretty braindead.
>
>
> Yeah, I wish some flash manufacturer would do the right thing and  
> just stick some NAND chips and some PCI/PCIe glue on a CardBus/ 
> ExpressCard. Something that allows a Linux driver to talk directly  
> to the flash chips and then a simple DMA engine to do bus mastering  
> block transfers to and from memory.  We could then run yaffs or  
> whatever we wanted on it with no translation layers at all in between.
>
>> But as far as CF is concerned I have tested many and not found a
>> single one that is suitable for a regular (random) filesystem write
>> workload.  To the extent that for embedded devices I ended up putting
>> a root filesystem tarball on the CF and unpacking it into ramfs  
>> during
>> boot.
>> And just to give you an idea: I'm getting two orders of magnitude  
>> less
>> random write ops on a (high-performance) CF than on a flash SSD from
>> the same vendor.  In both cases with I/O aligned to the flash page
>> boundary.
>
> That sounds just horrid.  Oh well, I won't have much choice when my  
> hard drive dies, drives in this form factor are not manufactured any  
> more and the only thing that will fit into the slot is a Compact  
> Flash card or maybe with some hacking a USB drive.  :-)

Speaking in general terms...

One approach you might consider in the meantime is to construct a  
LiveCD type system on your USB drive, and reserve a separate writable  
partition for storing your home directory.

LiveCD systems are stored in compressed images.  The root file system  
is expanded in one sequential shot and loaded into the system's RAM to  
mitigate the expense of seeks on optical media.  But the root file  
system is also read-only, which is ideal for flash media.

Check out http://www.pendrivelinux.com/ for details.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com