Subject: Re: Solaris 2.4

From: [email-masked] (Ian Donaldson)
Date: Sun, 15 May 1994 04:49:22 GMT

[email-masked] (Antonio Vasconcelos) writes:

>[email-masked] (Richard M. Mathews) writes:
>: My understanding of the journalled file system is that it is just UFS plus
>: a log.  The log is stored in a separate device.  There is no change at
>: all to the UFS format or to backup, newfs, etc.  If you remove the log,
>: you revert to old-style UFS operation.  Adding journalling to existing
>: file systems is certainly optional.

>That's not my understanding of journalled file system. As I understand
>it, it's saffer than an usual fs, ok, but that's not the major
>improvment, the fact is that it should be possible to increase the
>size of a file system if you have unallocated space on disk, and with
>the filesystem on-line.

What has dynamically increassing the size of a filesystem got to do
with journalling?  It should be possible with UFS to dyamically
increase its size, by simply writing more cylinder groups at the end
and updating all the super blocks to say there are more inodes...
(presumably there is a virtual to physical mapping available to virtually
extend a partition onto another physical device or somesuch; trivial
things to do in software).  Reducing the size is more compilicated and
time consuming, as data beyond the new size would need to be moved to 
other inodes.

The things important with journalling include:

- fast crash recovery.  Very little time spent in "fsck" type programs.

- better crash recovery.  Very little or no chance that a file will be lost,
  and a selection of previous versions to choose from.  Recovery
  can invole replay of recent activity from separate log(s).

- better write performance.  If designed right, delays due to synchronous 
  write's should not be required.  (of course there are other ways
  to achieve this, such as things like PrestoServ NVRAM but that's extra
  hardware)

Other improvements could also be done to enhance security also...
for example by having each block have a back pointer to the inode that
owns it, so that one person's data can't easily appear in another's inode
due to a crash where data gets written to the wrong sectors (a common
thing with flakey hardware or kernel bugs).  There is of course a slight space
cost with this.  But this is not anything to do with journalling either;
just something one hopes would go into any new filesystem design.

Ian D