kern/62228: Kernel improperly identifies partition size of concat (grown) vinum volume

[Bart Kus]

>Number:         62228
>Category:       kern
>Synopsis:       Kernel improperly identifies partition size of concat (grown) vinum volume
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Feb 01 13:50:17 PST 2004
>Closed-Date:
>Last-Modified:
>Originator:     Bart Kus
>Release:        FreeBSD 5.2.1-RC i386
>Organization:
>Environment:
FreeBSD XXXXXXXXXX.XX.shawcable.net 5.2.1-RC FreeBSD 5.2.1-RC #0: Sun Feb  1 14:50:20 CST 2004     eo at XXXXXXX.XX.shawcable.net:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
      I've ran 4.x on this machine a long time.  I started a org-concat vinum volume with a single 60GB drive.  Then I added a 120GB, performed a growfs.  Then I added a 160GB and performed another growfs.  The total (formatted) partition size should be over 300GB now (and was recognized as such by the 4.9 kernel when mounted).

Then I upgraded to FreeBSD-5.  Vinum recognizes the volume as:

vinum -> l
3 drives:
D ibm1                  State: up       /dev/ad7s1e     A: 0/58644 MB (0%)
D wd1                   State: up       /dev/ad6s1e     A: 0/114470 MB (0%)
D wd2                   State: up       /dev/ad2s1e     A: 0/152625 MB (0%)

1 volumes:
V media                 State: up       Plexes:       1 Size:        318 GB

1 plexes:
P media.p0            C State: up       Subdisks:     3 Size:        318 GB

3 subdisks:
S media.p0.s2           State: up       D: wd2          Size:        149 GB
S media.p0.s0           State: up       D: ibm1         Size:         57 GB
S media.p0.s1           State: up       D: wd1          Size:        111 GB

However, the kernel only sees the volume as:

/dev/vinum/media 171823499 146003951 25819548    85%    /usr/local/media
aka:
/dev/vinum/media   164G   139G    25G    85%    /usr/local/media

164G was the exact size of the partition before the 2nd growfs operation in 4.9-space (60GB+120GB, formatted).

One might suppose I just need to re-run growfs, however the file system hasn't lost a single file.  In fact, the file system currently holds more than 164GB of data (and still has room to allow for writing):

su-2.05b# cd /usr/local/media
su-2.05b# du -sk
195785335       .
su-2.05b# dd if=/dev/zero of=bigfile bs=1024k count=100
100+0 records in
100+0 records out
104857600 bytes transferred in 6.362625 secs (16480242 bytes/sec)

Why was this mis-reporting problem given a priority of high and severity of serious?  Because:

su-2.05b# cd
su-2.05b# umount /usr/local/media
su-2.05b# fsck /dev/vinum/media 
** /dev/vinum/media
** Last Mounted on /usr/local/media
** Phase 1 - Check Blocks and Sizes
fsck: /dev/vinum/media: Segmentation fault
su-2.05b# ls -l *.core
-rw-------  1 root  wheel  22872064 Feb  1 15:37 fsck_ufs.core

So now I'm left without the ability to fix up the file system should anything happen (power outage).  fsck doesn't seem to corrupt the file system before it crashes at least.

Furthermore, I'm not sure if this is normal:

su-2.05b# disklabel /dev/vinum/media
disklabel: /dev/vinum/media: no valid label found

But in any case, I suspect fsck's and disklabel's weird behaviour can be attributed to the original problem of mis-reading the file system data in the kernel.
>How-To-Repeat:
      Not sure exactly, but try: Grow a concat-organized vinum volume twice under 4.9, mount volume under FreeBSD-5.2*.  (Perhaps exceed 300GB partition size?)
>Fix:
      
>Release-Note:
>Audit-Trail:
>Unformatted: