> It could also be that some program is still running which has a file in
> /a open. That would also explain why the space is still shown as
> allocated.
No other files were open; it was preceded by an "*rm -rf /a/**" cmd.
But even after doing that, umounting it, and re-mounting it, I find:
*# pwd/root# umount /a# mount_msdos /dev/sd2a /a# df -h /aFilesystem
Size Used Avail %Cap Mounted on/dev/sd2a 1.4M
31K 1.4M 2% /a# ls -la /a total 1drwxr-xr-x 1 root wheel 7168
Jan 1 1980 ./drwxr-xr-x 32 root wheel 1024 Dec 29 02:38 ../*
Hmmm, somehow 31K are still used. Used for what? Now, I know that on
some filesystems, there is some 'hidden' disk space, which only root can
access.
Back in windows, 32,256 bytes (63 sectors) are seen to be 'used' - but
there are no files.
Is NetBSD 'reserving' some sectors for some reason? (As I say, normally
after formatting, windows only marks sectors 'used' that are bad; and this
particular diskette has 2 bad sectors (1,024 bytes)). Reformatting on
Windows gives the 1,024 'used' bytes, and 1,456,640 'available' bytes, a
capacity of 1,457,664 bytes. Now, the entire disk is 2880 sectors of 512
bytes each, hence 1,474,560 bytes; so the Directory uses 1,474,560 -
1,457,664 =16,896 bytes, or 33 sectors.
Back on NetBSD, I get this oddness:
*# mount_msdos /dev/sd2a /a mount_msdos: /dev/sd2a on /a: Operation not
supported by device# mount_msdos /dev/sd2a /a *
*#*
OK, no big deal, but not sure why -- after a successful umount previously
and ejection of the diskette -- that the error message is generated upon a
new mount.
*# df -h /a*
*Filesystem Size Used Avail %Cap Mounted on/dev/sd2a
1.4M 1.0K 1.4M 0% /aarm64# ls -la /a total 1drwxr-xr-x
1 root wheel 7168 Jan 1 1980 ./drwxr-xr-x 32 root wheel 1024 Dec 29
02:38 ../drwxr-xr-x 1 root wheel 512 Jan 5 14:19 System Volume
Information/# ls -la /a/System\ Volume\ Information *
*total 1-rwxr-xr-x 1 root wheel 76 Jan 5 14:19 IndexerVolumeGuid**
This all looks reasonable, except perhaps the 1.0K 'Used' field. (1K is
bad blocks; and the IndexerVolumeGuid is only 76 bytes, which would consume
1 sector of 512 bytes, therefore the 'Used' should presumably be "1,5K" ?)
*# df -G /a *
* /a (/dev/sd2a ): 512 block size 512 frag size
2847 total blocks 2845 free blocks 2845 available 0
total files 224 free files 1810 filesys id msdos fstype
0x1000 flag 255 filename length 0 owner
0 syncwrites 0 asyncwrites*
There are 2880 total sectors, and the directory uses 33 sectors, meaning
the max# of available sectors is 2847, as is reported. 2 sectors are bad,
hence 2845 actual free blocks.
But: Where is *System Volume Information/**IndexerVolumeGuid *stored?
Writing the biggest possible file (given there are 2 bad sectors):
*# dd if=/dev/urandom of=big bs=1456640 count=1 1+0 records in1+0 records
out1456640 bytes transferred in 0.063 secs (23121269 bytes/sec)# time cp
big /a cp -pi big /a 0.00s user 0.01s system 0% cpu 14.627 total*
Clearly, the writes are buffered, as it takes about a minute to write all
cylinders.
*# df -G /a /a (/dev/sd2a ): 512 block size 512 frag
size 2847 total blocks 0 free blocks 0 available
0 total files 224 free files 1810 filesys id msdos
fstype 0x1000 flag 255 filename length 0
owner 4 syncwrites 6 asyncwrites# ls -la
/adrwxr-xr-x 1 root wheel 7168 Jan 1 1980 ./drwxr-xr-x 32 root
wheel 1024 Dec 29 02:38 ../drwxr-xr-x 1 root wheel 512 Jan 5
14:19 System Volume Information/-rwxr-xr-x 1 root wheel 1456640 Jan 5
22:37 big**
So *System Volume Information/**IndexerVolumeGuid *is stored 'someplace
special', it would seem.
And now, this is the the part I really don't understand:
*# rm -rf /a/*zsh: sure you want to delete all the files in /a [yn]?
yarm64# ls -la /atotal 1drwxr-xr-x 1 root wheel 7168 Jan 1 1980
./drwxr-xr-x 32 root wheel 1024 Dec 29 02:38 ../arm64# df -G /a
/a (/dev/sd2a ): 512 block size 512 frag size 2847
total blocks 899 free blocks 899 available 0 total
files 224 free files 1810 filesys id msdos fstype
0x1000 flag 255 filename length 0 owner
7 syncwrites 12 asyncwrites*
-Mike
On Thu, Jan 5, 2023 at 2:07 PM <g...@duzan.org> wrote:
> > On 1/5/23 21:32, Michael Cheponis wrote:
> >> fascinatingly, now, when I try to "umount" the filesystem:
> >>
> >> *# umount /a
> >> umount: /a: Device busy*
> >
> > Fascinating, from what you wrote you might still "be" in /a
> >
> > regards,
> > chris
> >
>
> It could also be that some program is still running which has a file in
> /a open. That would also explain why the space is still shown as
> allocated.
>
> Gary Duzan
>
>
>
>
