newfs: useless/bogus check if new last block can be accessed?

[Poul-Henning Kamp]

In message <20030509234356.T638 at korben.in.tern>, Lukas Ertl writes:
>Hi fs-hackers,
>
>since I'm currently having fun in getting familiar with UFS/FFS and all
>its related tools, I found the following piece of code in sbin/newfs/mkfs.c:
>
>[...]
>
>I quite clueless why that wtfs() call is there at all and how it should
>"verify that its last block can actually be accessed".
>
>wtfs() is of type static void, and just calls bwrite() from libufs,
>ignoring its return value.
>
>Anyone can shed some light on this?

In the good old days, people could write any damn number they wanted in
a disklabel, and the kernel would let them.

This check tried to make sure that the partition length picked up from
the disklabel, or entered as an argument actually makes sense as far
as you can actually write to the last sector.

I'm not sure if this particular bit does anything at this point in
time, we may have caught the issue earlier in the process, because
today disk devices actually know how large they are.

syv# mdconfig -a -t malloc -s 1m -u 5
syv# diskinfo /dev/md5
/dev/md5        512     1048576 2048
syv# newfs -s 2047 md5
/dev/md5: 1.0MB (2044 sectors) block size 16384, fragment size 2048
        using 1 cylinder groups of 1.00MB, 63 blks, 128 inodes.
super-block backups (for fsck -b #) at:
 32
syv# newfs -s 2048 md5
/dev/md5: 1.0MB (2048 sectors) block size 16384, fragment size 2048
        using 1 cylinder groups of 1.00MB, 64 blks, 128 inodes.
super-block backups (for fsck -b #) at:
 32
syv# newfs -s 2049 md5
newfs: /dev/md5: maximum file system size is 2048
syv# 

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.