> From: kim@dde.dk (Kim Andersen)
> Subject: Puzzling questions about FFS
> To: tech-kern@NetBSD.ORG
> Date: Fri, 28 Oct 94 17:58:51 DNT
> 
> There's a never ending discussion going on in comp.os.linux.development
> regarding problems and virtues of Linux's ext2fs filesytem and FFS.
> 
> One of the things that keeps surfacing is that the synchronous writes of
> inodes are wrong, and could lead to security failures.
> 
> As I havent studied the code in either file system too closely, I would like
> someone to comment on the validity of the statements.
> 
> It was written in one article:
> >As someone pointed out, the only way to ensure file system integrity is to
> >write out first data blocks, then indirect blocks and then the inode. FFS
> >does the opposite which is at best useless, at worst wrong.
> 
> (This is supposed to be the way linux does it)
> 
> How can this model be better then the opposite .
> I would think that it mainly were a question of locking the datablocks, 
> 
> I must say that i haven't seen any problems with FFS, even when abusing
> the file-system eg. removing power during massive writes.
> 

You need to define what you mean by "security" and "integrity".
For "security", I think: can someone get access to data that they should
not be able to.  In this sense, there is a possible security problem:

	a block is allocated to a file
	block is zeroed in the buffer cache but not on disk
	block is allowed to be written back asynchronously
	the block number is recorded in the inode/indir-block
	inode/indir-block is written back to disk before the block

Now there is a window after the block number was written back but before
the new contents of the block itself is.  If the machine crashes during this
window, the file will have the old contents for that block.

There is an upcoming OSDI paper which talks about metadata update issues:

	Metadata Update Performance in File Systems
	Gregory R. Granger and Yale N. Patt, U. of Michigan