Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes

[Ric Wheeler]

Just a couple of comments about barriers that might be worth throwing in 
the mix.

From what I have seen, running with barriers is almost always a win 
over running with write cache disabled for medium to large files (large 
files with a S-ATA drive go about twice as fast in my testing).

For very small files, running with the barrier or disabling the write 
cache are a lot closer in performance.

When we are looking for ways to batch, it is also critical to keep in 
mind the latency of the storage. The current ext3 transaction batching 
code makes running multi-threaded workloads on high speed media (like 
non-volatile disk arrays) run much slower.   (Josef had some patches 
which helped fix this in a similar way that XFS deals with this.)

One other note is that moving to a FLASH based device will not make the 
issue of barriers go away since (most? all?) FLASH parts you are likely 
to see have their own write cache which is used to buffer up writes in 
order to make the erase cycle less painful. That means that we have a 
fairly large *volatile* write cache which needs to be flushed/controlled 
just like we do with S-ATA/SCSI/etc ;-)

ric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/