🚀 go-pugleaf

systems: all 4.3 systems (including ISI and MACH) that I have seen.

This has got to be a known bug.
I'm wondering if there is a known fix for it?

fsync in the ufs works in 2 different ways depending on the size of the file:

if it is < 1/2 of the size of the buffercache, it walks along the file
and checks if each block is in the cache, and if it is, and dirty, it
writes it to disk.

If the file is greated than 1/2 of the size of the buffer cache, it simply
examines every block in the buffer cache to see if it belongs to
that file, and if it does, it flushes it. (if dirty)

The problem occurs when the file is > N where N is the maximum size of a file
that can be stored without using the indirect blocks in the inode, 
If it is less than 1/2 the buffer cache, but greater than N in length, then
while all the DATA blocks get written out, dirty INDIRECTION blocks
are left until the next sync() before they are written out.

result: if there is a growing file, > 10 blocks long, but less than
1/2 the buffer cache in size, a crash will result in a file in which
the indirection blocks have not been written out correctly, making the 
file corrupt. If you are checkpointing with a log file, and using fsync,
Your checkpoints become useless as soon as the 10 direct blocks are used up.


I can't believe we are the first to see this, and I think it has been fixed
in the net2 release by the new dirty linked list associated with mountpoints and
file inodes, but does anybody know of a fix in 4.3 systems with the old
style of buffer management.?

julian
+----------------------------------+       ______ _  __
|   __--_|\  Julian Elischer       |       \     U \/ / On assignment
|  /       \ julian@tfs.com        +------>x   USA    \ in a very strange
| (   OZ    ) 2118 Milvia st. Berkeley CA. \___   ___ | country !
+- X_.---._/  USA+(510) 704-3137(wk)           \_/   \\            
          v