[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090827130252.GC14240@duck.novell.com>
Date: Thu, 27 Aug 2009 15:02:52 +0200
From: Jan Kara <jack@...e.cz>
To: Christoph Hellwig <hch@....de>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
chris.mason@...cle.com, jack@...e.cz, tytso@....edu,
adilger@....com, swhiteho@...hat.com,
konishi.ryusuke@....ntt.co.jp, mfasheh@...e.com,
joel.becker@...cle.com
Subject: Re: [PATCH] notes on volatile write caches vs fdatasync
Hi,
On Thu 27-08-09 03:16:24, Christoph Hellwig wrote:
> There are two related issues when dealing with volatile write caches,
> the popular and beaten to death one are write barriers to guarantee
> write ordering and stable storage for log writes. For this post
> I assume naively this works perfectly for all filesystems supporting it.
>
> The second issue are plain cache flush. Yes, they happen to be the
> base for the barrier implementation on all common disks in Linux, but
> there are cases where we need to issue them even without a log barrier.
>
> Think about a plain write into a file that is already fully allocated.
> Or the O_DIRECT version of them same. If we do an fdatasync after these
> we really do expect the write to really be on disk, not just in the disk
> cache, right? The same is true for O_SYNC, but I ignore it for this
> write out as with Jan's patch series O_SYNC writes will be implemented
> by a range-fdatasync after the actual write, so after that this sync
> section covers it, too.
I've noticed this as well when we were tracking some problems Pavel
Machek found with his USB stick. I even wrote a patch at the time
http://osdir.com/ml/linux-ext4/2009-01/msg00015.html
but it somehow died out. Now, the situation should be simpler with
fsync paths cleaned up... BTW: People wanted this to be configurable per
block device which probably makes sence...
Honza
--
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists