>>>>>> Here is some info on zflashpoint: >>>>>> >>>>>> http://forum.notebookreview.com/showthread.php?p=5163549 >>>>>> >>>>>> It is supposed to be an SSD performance "accelerator". >>>>>> >>>>>> "Gen1 SSDs suffer with small file writes and I read that 90% of >>>>>> Windows writes are small, so that introduces overall system lag. >>>>>> zflashpoint uses a 32MB buffer for small file writes, combining them >>>>>> and dumping them as one big write." >>>>>> >>>>>> Has anyone heard of development of a similar project for Linux? >>>>>> >>>>>> - Grant >>>>>> >>>>> Sounds like laptop-mode to me (app-laptop/laptop-mode-tools). For ext* >>>>> file systems, you can also try the 'commit' mount option. >>>> On her laptop, I get: >>>> >>>> # cat /proc/sys/vm/laptop_mode >>>> 0 >>>> >>>> There is lots of talk on the internet about the stuttering problems on >>>> SSD netbooks. Are you thinking this problem shouldn't manifest itself >>>> on a Linux system? >>>> >>>> - Grant >>>> >>> Well, as I see it, there are two distinct problems here: >>> 1. (Cheap) SSDs are slow >>> 2. (Cheap) SSDs are terribly slow on random write >>> >>> Both reasons can produce stuttering and you can't completely fix them. >>> However, you can try to cache random writes until you can commit them as >>> one sequential write. >>> >>> There are several things which will help here: >>> >>> 1. A file system that does not scatter data unnecessarily and which >>> might even align its (meta)data to the erase block boundaries of the SSD.[1] >>> >>> 2. A long commit interval in which writes can be collected until they >>> are actually performed in optimal order(see my last post). >> >> OK, I'm sorry, I thought you were telling me before she must be in >> laptop-mode. Now I see that laptop-mode can act as the cache. Has >> anyone actually reported laptop-mode helping ease the stuttering of >> slow SSDs? >> > > No need to apologize. > > Some additional thoughts: > > When you think about the situation, laptop-mode might actually make the > situation worse. You see, it was originally developed to help HDDs > staying in standby for longer periods by delaying writes until a read > action causes the drive to spin up or some period of time has passed. > > At this point, all writes should happen in one short burst. However, > with slow SSDs, these bursts might actually cause the stuttering you > experience. This is especially true when the writes delay a read action. > I'm not sure whether the disk scheduler prefers reads over writes but it > certainly would help. > > There is no need to keep an SSD idle as there is no kind of standby like > HDDs have.[1] Therefore I think a better solution would be treating > write actions as batch jobs: You do them only when there is nothing > better to do (i.e. no read action). Until then, you keep them in a large > write cache. > > I'm not sure if there is such a system, yet. Maybe you should try out > XFS as it already implements a very aggressive write cache. I'd be very > interested in benchmarks for Ext4 vs. XFS on slow SSDs > but I wouldn't bet on seeing one soon. I suppose simulating and > measuring such a usage pattern isn't a simple task. > > [1] Sure, an idle SSD still consumes less power than a busy one but you > can't really compare that to HDDs.
Thank you Florian. - Grant
