On 09.08.2009 16:13, Florian Philipp wrote:
[..]
> 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.

Reads do get higher priority by default.  They are synchronous afterall.
 Problem usually occurs when reads get interspersed with random writes,
i.e. when start you getting lots of seeks.

But good SSDs don't care.  Only HDDs do.  And maybe bad SSDs, too.

> 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.

It is not that easy (it never is?).  There are a lot of trade-offs as
can be witnessed by the variety and complexity of the disk schedulers.

> 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.

Well, work with email (email causes a lot of filesystem syncs typically)
while dd'ing a big file repeatedly in the background.  Should be close
enough.  Both latency (stutters) and throughput are important.

-- 
Eray

Reply via email to