lkml.org 
[lkml]   [1999]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectRe: fsync (+ small mremap patch)
On  9 Jul 99 at 12:43, I wrote:
> Hi MIngo, Alan, Andrea, Linus and others,
> two days ago I reported that fsync() does not work correctly (unfortunately,
> no one replied) and real 2.3.10 has same problem :-(
> After further investigation I found that if:
> (1) first fsync() was on file with length X (>= 1 disk block)
I forgot to mention 'on dirty file...'
> (2) file was truncated so that file length rounded up to block size
> is not multiple of page size (i.e. page has not all buffers;
> for example
> write(fd,buff,4096);fsync(fd);ftruncate(fd,4096-1024);fsync(fd);
> (3) then second fsync() fails.
... because of buffer_req() is set from previous I/O, but
flushpage() cleared uptodate (and mapped), but not req.

To follow up myself, after doing this change:

--- linux/fs/buffer.c Wed Jul 7 11:56:20 1999
+++ linux/fs/buffer.c Fri Jul 9 16:20:15 1999
@@ -1270,6 +1270,9 @@
mark_buffer_clean(bh);
clear_bit(BH_Uptodate, &bh->b_state);
clear_bit(BH_Mapped, &bh->b_state);
+ /* VANA: otherwise there is Req, but not uptodate buffer
+ and fsync is not happy from this... */
+ clear_bit(BH_Req, &bh->b_state);
bh->b_blocknr = 0;
atomic_dec(&bh->b_count);
}
\End of patch
my system works again. I installed 98MB of debian packages and it looks
like that filesystem is OK. I do not know, whether it is best - I do not
understand, what BH_Req should mean, as no-one except fsync_dev/set_blocksize
clears it, if I did not miss something... But if fsync_dev clears
BH_Req, should not dropping buffer clear this too?! But I can say
that I still do not understand this...
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz

P.S.: My mail client converts tabs to space, so I'm attaching patch
above as gzipped binary file.This message contains a file prepared for transmission using the
MIME BASE64 transfer encoding scheme. If you are using Pegasus
Mail or another MIME-compliant system, you should be able to extract
it from within your mailer. If you cannot, please ask your system
administrator for help.

---- File information -----------
File: BUFF.GZ
Date: 9 Jul 1999, 16:41
Size: 280 bytes.
Type: Binary
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.027 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site