[comp.bugs.4bsd] 4.3BSD conversion question...

dantso@bach.UUCP (04/09/87)

	Sorry if this has been talked about before...

	We are in the middle of converting from 4.2BSD to Mt Xinu 4.3BSD+NFS.
I noticed that when running 4.3BSD's fsck on 4.2BSD filesystems that it
complains that the 4.2BSD directories are not multiples of 512 and ask to
correct it.
	Should I say yes ? I hope I don't have to dump/restore all my 4.2BSD
filesystems...
	Thanks.

dan@rna.UUCP (04/09/87)

	Sorry if this has been talked about before...

	We are in the middle of converting from 4.2BSD to Mt Xinu 4.3BSD+NFS.
I noticed that when running 4.3BSD's fsck on 4.2BSD filesystems that it
complains that the 4.2BSD directories are not multiples of 512 and ask to
correct it.
	Should I say yes ? I hope I don't have to dump/restore all my 4.2BSD
filesystems...
	Thanks.

					Cheers,
					Dan Ts'o
					Dept. Neurobiology
					Rockefeller Univ.
					1230 York Ave.
					NY, NY 10021
					212-570-7671
					...cmcl2!rna!dan
					rna!dan@cmcl2.arpa

stevesu@copper.UUCP (04/11/87)

In article <622@rna.UUCP>, dan@rna.UUCP (Dan Ts'o) writes:
> I noticed that when running 4.3BSD's fsck on 4.2BSD filesystems that it
> complains that the 4.2BSD directories are not multiples of 512 and ask to
> correct it.

I was just reading through the 4.3 documentation, and I came
across the following note ("Changes to the Kernel in 4.3BSD,"
section 4, under ufs_syscalls.c):

	_M_k_d_i_r now sets the size of all new directories to
	DIRBLKSIZE.

Now, DIRBLKSIZE is DEV_BSIZE which is 512, and it's not
inconceivable that efforts are also made to keep a directory a
multiple of 512 bytes long once some real files are created
within it.  (For all I know, the 4.2 kernel does this too.)

It would guess that the 512 character enforcement is just an
efficiency tweak, although for a fully upgraded 4.3 filesystem,
fsck's message would be a warning that 4.3 isn't keeping the
directories as aligned as it thinks it is.

In any case, I wouldn't worry about the warning, or about letting
fsck fix the "problem."

                                           Steve Summit
                                           stevesu@copper.tek.com