Grant schrieb: >>>>> 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.
signature.asc
Description: OpenPGP digital signature
