| To: | Martin Steigerwald <Martin@xxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Extreme slowness with xfs [WAS: Re: Slowness with new pc] |
| From: | Dave Chinner <david@xxxxxxxxxxxxx> |
| Date: | Thu, 27 Nov 2008 08:43:08 +1100 |
| Cc: | xfs@xxxxxxxxxxx |
| In-reply-to: | <200811261330.27328.Martin@xxxxxxxxxxxx> |
| Mail-followup-to: | Martin Steigerwald <Martin@xxxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| References: | <1226760254.5089.11.camel@chevrolet> <492B5684.2080107@xxxxxxxxxxx> <1227647010.7992.34.camel@chevrolet> <200811261330.27328.Martin@xxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.18 (2008-05-17) |
On Wed, Nov 26, 2008 at 01:30:26PM +0100, Martin Steigerwald wrote: > I wonder whether XFS performance with barriers enabled can be improved? Not really. It requires fundamentally altering the way the transaction system works, and that's no easy task. I have a few things that I'm looking at, but nothing that would be considered short-term.... > And whether XFS with disabled write cache (via hdparm) but without > barriers might even be *faster* than XFS with barriers... One thing to > test eventually. Yes, it often is with SATA drives - it depends on the quality of the NCQ implementation in the drive. For SCSI drives, no write cache or barriers is almost always faster than using WC+barriers. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [PATCH, RFC] - xfsprogs: pad ustat struct for mount check to avoid corruption, Eric Sandeen |
|---|---|
| Next by Date: | Re: truncated files, Dave Chinner |
| Previous by Thread: | Re: Extreme slowness with xfs [WAS: Re: Slowness with new pc], Martin Steigerwald |
| Next by Thread: | fatal error -- bad magic # (0x0) for directory data block (bno 0 fsbno 7), . . |
| Indexes: | [Date] [Thread] [Top] [All Lists] |