Re: port-xen/56782: panic: /: bad dir ino null entry

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR port-xen/56782; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Bartosz Maciejewski <bartosz%maciejewski.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, port-xen-maintainer%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: port-xen/56782: panic: /: bad dir ino null entry
Date: Sat, 09 Apr 2022 03:23:05 +0700

     Date:        Fri, 8 Apr 2022 09:38:22 +0200
     From:        Bartosz Maciejewski <bartosz=40maciejewski.org>
     Message-ID:  <39d456e2-e694-8291-1072-e1913bd10e39=40maciejewski.org>=
 
 
   =7C Guest disk (one with problem). This is maximum disk size of 2TB tha=
 t=20
   =7C XCP-NG (Hypervisor/Domo) can create. There is still 0,5TB free spac=
 e.
 
 Actually, 2000 TiB which is not 2TB by anyone's reckoning (drive
 manufacturers call 2TB 2 * 10=5E12 bytes, most of us, call it 2 * 2=5E40)=
 
 But that's irrelevant, its size is its size, and anything big enough
 should work.   The free space is (for this purpose) even less relevant.
 
 The data you provided would be easier to read if it wasn't full
 of unpaddable spaces, seemingly cut & paste from some terminal
 emulator, if there is a need for something like this again, it
 would be better to, instead of ...
 
   =7C =23 dmesg =7C grep xbd
 
 do
 
 	cmesg =7C grep xbd >/tmp/file
 
 and then simply add /tmp/file to the message (inserted, rather than
 attached, if possible, but not cut&paste).
 
 
   =7C =23 disklabel xbd0
 
 All of this looks OK.
 
 
   =7C =23 cat /etc/fstab
 
 This one looks weird, but I suspect that's just an artifact of
 the terminal emulator, and the cut & paste, as the df output shows
 that the filesystems were mounted in their proper places, despite what
 this file looks like as presented here.
 
 
 
   =7C Content of /run/sr-mount/f5c40583-1708-0f1d-cdfc-d3459226e19b=20
   =7C (higlighted is NetBSD disk)
 
   =7C *-rw-r--r-- 1 root root 1580913943040 Apr=C2=A0 8 09:35=20
   =7C 3d41c559-7edb-4fe7-8f98-bd50e21d0e3a.vhd*
 
 That I believe was that one.   (The *'s or bold chars in the html version=
  of
 this message, as the highlighting indicated.)
 
 That's very interesting.  The 2000 GiB should be 2147483648000 bytes
 whereas that file is just 1580913943040 bytes (unless another cut&paste
 misrepresentation has muddied the waters).
 
 I will rewrite those numbers one above the other for easier comparison:
 
 	2147483648000		NetBSD filesystem size (in bytes)
 	1580913943040		.vhd file size (in bytes, I presume, it is just ls -l)
 
 I know nothing of your Dom0 system, nor its virtual discs, nor how one
 that is apparently just a bit less than 1500 GiB is able to appear in
 NetBSD as being 2000 GiB big.
 
 Note that it isn't even the full 'a' partition size, nor even close
 enough to it to reach as far as the final cylinder group header (if
 the file were only being allocated when space was actually touched,
 more than this much should have been touched just by the newfs that
 made the filesystem, before any data was even added).
 
 None of the other files you showed in that listing look to be even
 close to being big enough to hold the NetBSD filesystem.
 
 But if all of this is as represented, this is very likely the cause of
 the problems, but just how those actually occur, I am unable to say (I'd
 guess something wrapping around in the file, somehow, but that would be
 very very weird, very very buggy, and bizarre ... and nothing to do with
 NetBSD.)
 
 
   =7C Hope this helps.
 
 We need to see if this really is the issue, if it is, then yes, it
 did, otherwise, perhaps not.
 
 kre