From: Eric Sandeen <sandeen@sgi.com>
To: LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH] 2.4.19 place buffer dirtied in truncate() on inode's dirty data list
Date: 24 Sep 2002 13:23:29 -0500 [thread overview]
Message-ID: <1032891809.4190.108.camel@stout.americas.sgi.com> (raw)
This is for 2.4.x:
block_truncate_page() does a __mark_buffer_dirty(bh) at the end, but it
does not file the buffer on the inode's dirty data queue, so only
bdflush can ever get to it, and other sync mechanisms which call
fsync_inode_data_buffers() do not see it.
This was causing a particular problem with O_DIRECT on an xfs
filesystem, since O_DIRECT tries to sync before doing the I/O.
Following a truncate(), O_DIRECT reads of the last block were not
returning the correct data, since the truncate never got synced down to
disk.
ext2 does not seem to be able to do an O_DIRECT read of the last
filesytem block, unless the file size is a multiple of block size, so it
doesn't show up there.
--- linux/fs/buffer.c_1.109 Mon Sep 23 13:10:56 2002
+++ linux/fs/buffer.c Mon Sep 23 13:04:44 2002
@@ -2028,7 +2028,12 @@
flush_dcache_page(page);
kunmap(page);
- __mark_buffer_dirty(bh);
+ if (!atomic_set_buffer_dirty(bh)) {
+ __mark_dirty(bh);
+ buffer_insert_inode_data_queue(bh, inode);
+ balance_dirty();
+ }
+
err = 0;
The balance_dirty() call is debatable, Andrew Morton pointed out that it
does add a bit more risk. OTOH, if you go off and truncate a million
files in a row, you'll be in sorry shape without it.
2.5 apparently does not have this problem, it calls mark_buffer_dirty()
which seems to take care of things.
-Eric
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@sgi.com SGI, Inc. 651-683-3102
reply other threads:[~2002-09-24 18:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1032891809.4190.108.camel@stout.americas.sgi.com \
--to=sandeen@sgi.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).