[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090114182706.GA24719@elf.ucw.cz>
Date: Wed, 14 Jan 2009 19:27:06 +0100
From: Pavel Machek <pavel@...e.cz>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ext2: Add blk_issue_flush() to syncing paths
Hi!
> Also, the changelog needs some work, methinks.
>
> /**
> * blkdev_issue_flush - queue a flush
> * @bdev: blockdev to issue flush for
> * @error_sector: error sector
> *
> * Description:
> * Issue a flush for the block device in question. Caller can supply
> * room for storing the error offset in case of a flush error, if they
> * wish to. Caller must run wait_for_completion() on its own.
> */
>
> So afaict the change you've made is incomplete. We'll queue a
> writeback command to the disk but we won't wait for it to be sent down
> the wire. Nor do we wait for the command to complete at the device
> end. So it can still be a looong time (seconds!) before the data which
> the user thinks is on disk really is safe.
>
> Yes?
>
> If so, this design decision should be described in the changelog, and
> justified. Actually, doing this in the comment over
> ext3_blkdev_issue_flush() would be good.
Actually, if sync() and fsync() do not work, it probably needs more
than a comment in changelog. Like comment in documentation, in big
bold letters.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists