>
>
> John,
>
> The suggestion that knowing what files are open was only intended as a
> suggestion to completely eliminate any fsck - it wasn't my primary
> assertion. My primary assertion is: changes to the _structure_ on the disk
> must be reflected on the disk ASAP. This can be done by many different
> means, such as journaling - I have some concerns about that, primarily
> because I don't know enough about particular implementations, but also
> because I don't particularly like the concept of rebuilding on reboot.
> Also, it's not necessary to journal: Files-11 is an example of an on-disk
> file system which was exceptionally robust in terms of speed and
> data-integrety following a system halt/power outage.
>
> Please note that update of file access times is not at all important to me
How many of these fields are absolutely critical?
struct stat {
unsigned short st_dev;
unsigned short __pad1;
unsigned long st_ino;
unsigned short st_mode;
unsigned short st_nlink;
unsigned short st_uid;
unsigned short st_gid;
unsigned short st_rdev;
unsigned short __pad2;
unsigned long st_size;
unsigned long st_blksize;
unsigned long st_blocks;
unsigned long st_atime;
unsigned long __unused1;
unsigned long st_mtime;
unsigned long __unused2;
unsigned long st_ctime;
unsigned long __unused3;
unsigned long __unused4;
unsigned long __unused5;
};
I contend none of the time fields is. Not the permissions bits. A
non-written nlinks change is no worse than a failed file copy - you
don't lose data. Size? Must be consistent with the data written, but I
don't see it as more important than that.
Many times a half-written file is no use at all; the loss of all
filesystem data about half a wordprocessor document is no loss at all.
> or much anyone else, and I wasn't referring to that. The method by which
> Files-11, as an example, kept track of open files was to periodically
> write out a bitmap reflecting the headers (i-nodes) that were open for
> write access. After the wide-spread addoption of logical block disk access
> around 1982, it became possible to hand tasks to the disk controller and
> let it write less important data when convenient and other data instantly.
> ... I have no idea what modern IDE and SCSI drives do in this regard, but
> I'd be VERY surprised if they don't present a logical-block view of the
> world to their users while they do bad-block re-vectoring and so forth.
I used to program for the OS family. There was no concept of a
filesystem there - one used access methods, and those access methods
provided buffering or not: VSAM, QSAM & QISAM buffer, BDAM, BSAN, EXCP
& BISAM don't.
Those that buffer don't give the application much control over it,
those that don't buffer always do non-blocking I/O.
This design originated in the 60s (VSAM in the 70s). It wasn't until
the mid 80s that disk controllers had caching, and then there was lots
of hoo-haa about terms such as write-back, write through and what could
be cached and not, what should be cached and not and why THEIR claims
about OUR caching algorithms were wrong.
--
Cheers
John Summerfield
Microsoft's most solid OS: http://www.geocities.com/rcwoolley/
Note: mail delivered to me is deemed to be intended for me, for my disposition.
==============================
If you don't like being told you're wrong,
be right!
