Re: fsync (+ small mremap patch)

Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Fri, 9 Jul 1999 16:51:12 MET-1


--Message-Boundary-12397
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

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.
--Message-Boundary-12397
Content-type: text/plain; charset=US-ASCII
Content-description: Information about this message.

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

--Message-Boundary-12397
Content-type: Application/Octet-stream; name=BUFF.GZ; type=Binary
Content-transfer-encoding: BASE64

H4sICAgKhjcAA2J1ZmYAbY5LT8MwEITPza+YEwrNq6nUVgkCpRwQQoIDEnCMYsdRrCZ28EPQ
A/+dpM4FEV/Wu/vN7ERRhI4L+500OiG2aZiK6eqD1XiyHXBAmua7fb7dIM2yzAuCYAF/UNzh
GdKJzdOdw4sCUbo9bMI9gkvNUBQeVuPrK3UqnUNJO1YJn7TXN2439aok3Pj3j+XbYGRdGRbi
irTRHSm1GbtF9LkaBlb/A4MJTNZ4P74cc0jTMvXFNcP0YeAar+wzBLEGQhrY+R5cOKcGUIka
jT4LOikmsB2vndEo2Y9OXMdxjHXi8D+pLu5L2d2IdJKehMItNvO8MrLntKwZ9WcZlVaYWfbj
/QLI2TbStAEAAA==

--Message-Boundary-12397--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/