lkml.org 
[lkml]   [2008]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] (RESEND) ext3[34] barrier changes

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



\
 
 \ /
  Last update: 2008-05-23 20:37    [W:0.119 / U:1.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site