Re: CVS commit: src/sbin/newfs

[David Laight <david%l8s.co.uk@localhost>]

> > 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
uses randomndi_igen.

> > 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
superblock intact.

Both these are potentially file-system destroying!

        David

-- 
David Laight: david%l8s.co.uk@localhost