Messages in this thread | | | Date | Sat, 19 May 2007 11:18:17 -0400 | From | Bill Davidsen <> | Subject | Re: [PATCH] LogFS take three |
| |
Dongjun Shin wrote:
> There are so many flash-based storage and some disposable storages, > as you pointed out, have poor quality. I think it's mainly because these > are not designed for good quality, but for lowering the price. > The reliability seems to be appropriate to the common use. I'm doubious that computer storage was a big design factor until the last few years. A good argument for buying large sizes, they are more likely to be recent design.
> These kind of devices are not ready for things like power failure because > their use case is far from that. For example, removing flash card > while taking pictures using digital camera is not a common use case. > (there should be a written notice that this kind of action is against > the warranty) > They do well in such use, if you equate battery death to pulling the card (it may not be). I have tested that feature and not had a failure of any but the last item. Clearly not recommended, but sometimes unplanned needs arise.
> - In contrast to the embedded environment where CPU and flash is directly > connected, the I/O path between CPU and flash in PC environment is longer. > The latency for SW handshaking between CPU and flash will also be longer, > which would make the performance optimization harder. > > As I mentioned, some techniques like log-structured filesystem could > perform generally better on any kind of flash-based storage with FTL. > Although there are many kinds of FTL, it is commonly true that > it performs well under workload where sequential write is dominant. > > I also expect that FTL for PC environment will have better quality spec > than the disposable storage.
The recent technology announcements from Intel are encouraging in that respect.
-- Bill Davidsen <davidsen@tmr.com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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/
| |