/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 /a
Filesystem Size Used Avail %Cap Mounted on
/dev/sd2a 1.4M 31K 1.4M 2% /a
# ls -la /a
total 1
drwxr-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% /a
arm64# ls -la /a
total 1
drwxr-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 in
1+0 records out
1456640 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 /a
drwxr-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]? y
arm64# ls -la /a
total 1
drwxr-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