Subject: Re: CVS commit: src/sbin/newfs
To: Bill Studenmund <firstname.lastname@example.org>
From: David Laight <email@example.com>
Date: 09/05/2003 18:27:15
> > This all came in with the UFS2 support, however it was using cg_initediblk
> Ok, so I should blame someone else.
yes... Since they clearly didn't test the new code at all.
> While you're working on this, could you add an option to control this?
> Either the option causes the randomization, or disables it. I'd prefer
> enables it (not default), but if everyone screams for it, having it the
> default will be tollerable.
I'd go for the default being random numbers - because most people will
not realise just how weak NFS is without them!
For FFSv2 the kernel initialiases most of the inodes - I think it always
> > to determine how many of the inodes to initialise (ie randomise di_gen
> > and zero) - which got zeroed for UFS1. The rest of the inodes only get
> > initialised for UFS1 and were being given a random di_gen.
> > This fixed showed that when the directory inodes are written they (again)
> > picked up a zero di_gen.
> ?? Oh, we now once again give di_gen of zero? I'm confused.
Because an entire inode is generated for the directory, then copied into
the inode table - thus destroying the carefully generated random number.
Fun can also be had by replacing a FFSv2 filesystem with an FFSv1 filesystem
on a small volume. The FFSv2 superblock doesn't get overwritten!
This would be even more likely to be a problem if the FFSv2 superblock were
at offset 256kB.
Creating a FFSv2 filesystem over a FFSv1 one also leaves the original
Both these are potentially file-system destroying!
David Laight: firstname.lastname@example.org