Messages in this thread | | | Subject | Re: Linux 2.6.29 | From | Chris Mason <> | Date | Mon, 30 Mar 2009 14:52:29 -0400 |
| |
On Mon, 2009-03-30 at 14:39 -0400, Mark Lord wrote: > Chris Mason wrote: > > > > I had some fun trying things with this, and I've been able to reliably > > trigger stalls in write cache of ~60 seconds on my seagate 500GB sata > > drive. The worst I saw was 214 seconds. > .. > > I'd be more interested in how you managed that (above), > than the quite different test you describe below. > > Yes, different, I think. The test below just times how long a single > chunk of data might stay in-drive cache under constant load, > rather than how long it takes to flush the drive cache on command. > > Right? > > Still, useful for other stuff. >
That's right, it is testing for starvation in a single sector, not for how long the cache flush actually takes. But, your remark from higher up in the thread was this:
> > Anything in the drive's write cache very probably made > it to the media within a second or two of arriving there. > Sorry if I misread things. But the goal is just to show that it really does matter if we use a writeback cache with or without barriers. The test has two datasets:
1) An area that is constantly overwritten sequentially 2) A single sector that stores a critical bit of data.
#1 is the filesystem log, #2 is the filesystem super. This isn't a specialized workload ;)
-chris
| |