Also, how are they coping with the fundamental limitations of flash? As I understand it, on flash you can write a few sectors at one time, you can read as much as you like at a time, but you can't OVERwrite data in place, instead you have to write it somewhere else, and keep a note interally that the original location is now invalid and ought to be erased. Also you have to erase in BIG chunks which takes a long time. AND you also have to copy any data which is still valid to some other location before you can erase. In other words - LOADS of overhead.
So, to fit a filesystem such as NTFS which was designed around the assumption that you can write and overwrite without restriction onto a flash device, there must be a big overhead in marshalling all this data into the flash.
In addition, the device has to do wear levelling in order to prolong its life given the limit of X write-erase cycles. AND NTFS is notoriously bad for fragmentation. How does the device cope with that?
How would such a device cope with a swapfile, which may have small parts of it being overwritten VERY frequently?
Perhaps this should only be used on a machine with sufficent RAM that swap is not required....????
I'd be very interested in a real life review of a machine with a flash hard drive. I bet there are going to be all sorts of problems with it cropping up over time.
One problem is that filesystems are designed for the physical characteristics of a disk. If you want to overwrite a sector on a disk, you just point the head at the right place and write.
You can't do this on flash.
You can write minimum a page at a time. With parallelism in place this may be something like 32KB which is similar to cluster size on some filesystems so no problem there. However, you can't OVERwrite existing data. You have to write it somewhere else, and have control structures in place to know where it was put, and that the old data is now invalid. Then you have to consolidate the data in order to get the now obsolete storage back. You can only erase a block at a time, which could be in chunks of 1MB or so with parallelism.
So to change some text in the middle of a document, or swap a page of RAM to virtual memory, you will actually be doing CONSIDERABLY more actual reading/writing/erasing than the few bytes that the OS/filesystem assumes you're doing... because it's designed to use a disk.
So the performance numbers you see are for sustained sequential reads and writes. I'd be more interested in 'real' performance numbers for PC based operation. And... while this is a common caveat for disk benchmarks, it is WAY more of a significant issue for flash disks.
BTW, for just a few dollars you can make your own (small) SSD by purchasing a IDE-CF converter and plugging in a compact flash card. It's fast, cheap, silent and low powered. Ideal for your OS/boot partition. Just don't put a swapfile on it!
Slashdot Mirror
So, to fit a filesystem such as NTFS which was designed around the assumption that you can write and overwrite without restriction onto a flash device, there must be a big overhead in marshalling all this data into the flash.
In addition, the device has to do wear levelling in order to prolong its life given the limit of X write-erase cycles. AND NTFS is notoriously bad for fragmentation. How does the device cope with that?
How would such a device cope with a swapfile, which may have small parts of it being overwritten VERY frequently?
Perhaps this should only be used on a machine with sufficent RAM that swap is not required....????
I'd be very interested in a real life review of a machine with a flash hard drive. I bet there are going to be all sorts of problems with it cropping up over time.
You can't do this on flash.
You can write minimum a page at a time. With parallelism in place this may be something like 32KB which is similar to cluster size on some filesystems so no problem there. However, you can't OVERwrite existing data. You have to write it somewhere else, and have control structures in place to know where it was put, and that the old data is now invalid. Then you have to consolidate the data in order to get the now obsolete storage back. You can only erase a block at a time, which could be in chunks of 1MB or so with parallelism.
So to change some text in the middle of a document, or swap a page of RAM to virtual memory, you will actually be doing CONSIDERABLY more actual reading/writing/erasing than the few bytes that the OS/filesystem assumes you're doing... because it's designed to use a disk.
So the performance numbers you see are for sustained sequential reads and writes. I'd be more interested in 'real' performance numbers for PC based operation. And... while this is a common caveat for disk benchmarks, it is WAY more of a significant issue for flash disks.
BTW, for just a few dollars you can make your own (small) SSD by purchasing a IDE-CF converter and plugging in a compact flash card. It's fast, cheap, silent and low powered. Ideal for your OS/boot partition. Just don't put a swapfile on it!