xfs
[Top] [All Lists]

Re: Device loses barrier support (was: Fixed patch for simple barriers.)

To: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Subject: Re: Device loses barrier support (was: Fixed patch for simple barriers.)
From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Thu, 4 Dec 2008 23:15:51 +0100
Cc: Andi Kleen <andi@xxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, Alasdair G Kergon <agk@xxxxxxxxxx>, Andi Kleen <andi-suse@xxxxxxxxxxxxxx>, Milan Broz <mbroz@xxxxxxxxxx>
In-reply-to: <Pine.LNX.4.64.0812041401210.23079@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <Pine.LNX.4.64.0812040009340.15169@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081204100050.GN6703@xxxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0812040836480.6118@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081204142015.GQ6703@xxxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0812040913510.6118@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081204145810.GR6703@xxxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0812041139200.2434@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081204174838.GS6703@xxxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0812041401210.23079@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.4.2.1i
> If you are pushing what you are pushing --- barriers allowing to return 
> EOPNOTSUPP anytime --- then asynchronous barrier submits can no longer be 
> used, because by the time EOPNOTSUPP is detected, the filesystem is 
> already corrupted.

Chris Mason pointed out that this can actually already happen. From
a quick review this can happen in MD raid1 at least (their barriers_work
flag is pretty similar to the DM implementation I did).  So everyone
has to handle this already anyways.

> I'm wondering, where in fsync() does Linux wait for hardware disk cache to 
> be flushed? Isn't there a bug that fsync() will return before the cache is 
> flushed? I couldn't really find it. The last thing do_fsync calls is 
> filemap_fdatawait and it doesn't do cache flush (blkdev_issue_flush).

At least in fsync() on journaling fs the metadata update should push it.

-Andi

-- 
ak@xxxxxxxxxxxxxxx

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