home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / bugs / 4bsd / 218 < prev    next >
Encoding:
Text File  |  1992-09-15  |  2.2 KB  |  52 lines
  1. Newsgroups: comp.bugs.4bsd
  2. Path: sparky!uunet!spool.mu.edu!agate!tfs.com!julian
  3. From: julian@tfs.com (Julian Elischer)
  4. Subject: fsync bug on indirect blocks (probably known) got a fix?
  5. Message-ID: <1992Sep15.233420.26968@tfs.com>
  6. Organization: Trw Financial Systems
  7. Date: Tue, 15 Sep 1992 23:34:20 GMT
  8. Lines: 42
  9.  
  10. systems: all 4.3 systems (including ISI and MACH) that I have seen.
  11.  
  12. This has got to be a known bug.
  13. I'm wondering if there is a known fix for it?
  14.  
  15. fsync in the ufs works in 2 different ways depending on the size of the file:
  16.  
  17. if it is < 1/2 of the size of the buffercache, it walks along the file
  18. and checks if each block is in the cache, and if it is, and dirty, it
  19. writes it to disk.
  20.  
  21. If the file is greated than 1/2 of the size of the buffer cache, it simply
  22. examines every block in the buffer cache to see if it belongs to
  23. that file, and if it does, it flushes it. (if dirty)
  24.  
  25. The problem occurs when the file is > N where N is the maximum size of a file
  26. that can be stored without using the indirect blocks in the inode, 
  27. If it is less than 1/2 the buffer cache, but greater than N in length, then
  28. while all the DATA blocks get written out, dirty INDIRECTION blocks
  29. are left until the next sync() before they are written out.
  30.  
  31. result: if there is a growing file, > 10 blocks long, but less than
  32. 1/2 the buffer cache in size, a crash will result in a file in which
  33. the indirection blocks have not been written out correctly, making the 
  34. file corrupt. If you are checkpointing with a log file, and using fsync,
  35. Your checkpoints become useless as soon as the 10 direct blocks are used up.
  36.  
  37.  
  38. I can't believe we are the first to see this, and I think it has been fixed
  39. in the net2 release by the new dirty linked list associated with mountpoints and
  40. file inodes, but does anybody know of a fix in 4.3 systems with the old
  41. style of buffer management.?
  42.  
  43. julian
  44. +----------------------------------+       ______ _  __
  45. |   __--_|\  Julian Elischer       |       \     U \/ / On assignment
  46. |  /       \ julian@tfs.com        +------>x   USA    \ in a very strange
  47. | (   OZ    ) 2118 Milvia st. Berkeley CA. \___   ___ | country !
  48. +- X_.---._/  USA+(510) 704-3137(wk)           \_/   \\            
  49.           v
  50.  
  51.  
  52.