Charles Shattuck wrote: > > I did some experiments with BLOCK, UPDATE, and FLUSH. I notice that if > I update and flush say block 1, having started in a directory with no > BLOCKS.FB file, the directory isn't updated until blocks.fb is closed, > either explicitly or by saying BYE to gforth. My question is based on > not knowing much about operating systems (Linux in this case). When > does the updated an flushed block actually go onto the disk? If Linux > were to crash before blocks.fb were closed, would I find my data on > the disk later after rebooting?
Not necessarily. There are several levels of buffering involved here: 1) The programmer-visible buffering involving BUFFER etc. UPDATE, SAVE-BUFFERS, EMPTY-BUFFERS and FLUSH are used to manage that. 2) The buffering of the C stdio libray that Gforth's file words map to. SAVE-BUFFERS etc. should flush that too IMO, but in 0.5.0 does not. I have just changed this in the development sources, so the next release will. 3) The buffering of the file system in the OS. That depends on the file system and the mount options. Most file systems write data with some delay by default (e.g., typically up to 30s delay for ext2fs). For some file systems there are mount options allowing synchronous writing or somesuch, but usually they seriously hurt performance and are probably not very well tested. If you want to go that route, probably the best bet is to use ext3fs with the data=journal option. Alternatively, we could fsync or fdatasync the blocks.fb file after FLUSH-FILE, but Gforth currently does not have a primitive for fsync or fdatasync. Another alternative is to write the blocks to a block device (e.g., a hard disk partition) instead of a file on a file system. On Linux this writes synchronously in my experience. 4) The buffering of the disk drive. IDE drives typically do some writeback caching, and lose written data if power is lost (or a reset happens) before the data is written; they may reorder writes (in particular, in my experience they optimize writes away if later writes to the same block occur). You can turn this write buffering off under Linux with "hdparm -W 0 <drive>", but write performance can suffer a lot; if you use a file system that guarantees some consistency (e.g., ext3), you should turn this off anyway, otherwise you can forget about the consistency guarantee. - anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
