xfs
[Top] [All Lists]

Re: 3ware hardware raid with battery backup and the impact on barrier an

To: William Lewis <william@xxxxxxxxxxxxxx>
Subject: Re: 3ware hardware raid with battery backup and the impact on barrier and no write cache options.
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 02 Nov 2009 15:31:30 -0600
Cc: xfs@xxxxxxxxxxx
In-reply-to: <7a12b48b0911021202l126e10a1pbc281f6922380f48@xxxxxxxxxxxxxx>
References: <7a12b48b0911021202l126e10a1pbc281f6922380f48@xxxxxxxxxxxxxx>
User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
William Lewis wrote:
Hi,

I am in the process of setting up an XFS file system on underlying hardware consisting of a 3ware 9550SXU (+ battery backup module) and 4 x Seagate ST31500341AS 1.5TB hard drives in Raid 5 configuration.

Reading your FAQ at http://xfs.org/index.php/XFS_FAQ I understand that it is advisable to mount the file system with nobarrier to improve performance. However going on to read about recommended settings for write cache, the advice for 3ware hardware doesn't seem to account for the fact that there are 2 levels of write cache in play, that in the 3ware card itself protected by the battery and the write cache of the disks themselves, which as far as I can understand is also protected by the battery backup (in the correct storage modes - balanced/protection) because the 3ware card uses write journaling to keep track of pending write operations in the disks' cache. Therefore unless I am misunderstanding something the most benefit is to be gained by mounting with nobarrier and having the write cache turned on?

If the write caches won't go away - or will be fully/gracefully destaged before they do, then nobarrier should be safe.

One thing I am not clear about is if nobarrier interacts with the page cache at all and if the lack of barrier leaves you with a situation in which pending writes can be lost from main memory on power failure?

nobarrier has no interaction with the OS page cache; all the "barrier" option (the default) does is enforce ordering for journal IO*, and in practice it does this by flushing the cache at points in time.

-Eric

*well, I think it flushes the drive cache on fsync, too, for data integrity (vs. the metadata integrity for the journal IO ordering)

Thanks in advance for any clarification you can provide.

Regards

Will Lewis


------------------------------------------------------------------------

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs

<Prev in Thread] Current Thread [Next in Thread>