Ide card build issue.

[Brufnus]

What plexes me, is this... 248 MB should translate to 1015808 sectors, which in turn translates to F8000 in hex. The total AU is indeed set to F800 by both DU2k and MYS; hence, something else must be triggering these incorrect values?

 

Anyway, it seems to copy everything perfectly fine to that drive; once xcopy is done I'll compare the used and available disk space with an MFM image. If everything adds up, I'll just sector edit the VIB's for the time being.

[+InsaneMultitasker]

3 hours ago, Brufnus said:

Here's the SCSI VIB. c",) 

SCS1_VIB 8.13 kB · 1 download

Is this the VIB from the photo?  This bitmap is nearly full and there are subdirectory pointers in sector 0.

 

I need a copy of the VIB from the blank formatted disk - no files or directories - and the byte/sector count matching the picture.

20 hours ago, Brufnus said:

 

 

 

[+InsaneMultitasker]

44 minutes ago, Brufnus said:

What plexes me, is this... 248 MB should translate to 1015808 sectors, which in turn translates to F8000 in hex. The total AU is indeed set to F800 by both DU2k and MYS; hence, something else must be triggering these incorrect values?

The total AU word and the bitmap are two separate pieces of information. Depending on the routine, the total and available sectors may be computed by iterating through all 31 bitmap sectors - regardless of total AU count. It is here that I have found boundary-related problems in a few DSRs, including the horizon ROS and the Geneve OS.  One simple test is to edit sector 0, change >F800 to >F700, and see what happens to your counts.  It is very possible the routine to count the sectors is running past sector 31.

[Brufnus]

27 minutes ago, InsaneMultitasker said:

Is this the VIB from the photo?  This bitmap is nearly full and there are subdirectory pointers in sector 0.

 

I need a copy of the VIB from the blank formatted disk - no files or directories - and the byte/sector count matching the picture.

 

Yes, that's from that disk - newly formatted and should thus be empty. Now that's strange... c".)

[Brufnus]

15 minutes ago, InsaneMultitasker said:

The total AU word and the bitmap are two separate pieces of information. Depending on the routine, the total and available sectors may be computed by iterating through all 31 bitmap sectors - regardless of total AU count. It is here that I have found boundary-related problems in a few DSRs, including the horizon ROS and the Geneve OS.  One simple test is to edit sector 0, change >F800 to >F700, and see what happens to your counts.  It is very possible the routine to count the sectors is running past sector 31.

Okay, that part complicates things a bit of course. I'll try editing that sector as well. At the moment my copying seems to turn out fine; I'll double check the VIB though, it should be the correct one but just in case...

[+InsaneMultitasker]

28 minutes ago, Brufnus said:

Yes, that's from that disk - newly formatted and should thus be empty. Now that's strange... c".)

Definitely not empty.

>62 files and >55 subdirectories indicated. 

The bitmap has a lot of >FF (used) allocation units/sectors.

[Brufnus]

1 hour ago, InsaneMultitasker said:

Definitely not empty.

>62 files and >55 subdirectories indicated. 

The bitmap has a lot of >FF (used) allocation units/sectors.

I'll double check that, I might have made a mistake. 

[Brufnus]

So... here's a VIB dump from a freshly formatted and empty drive. If there's something I'm abundant of, it's SCA drives.  

 

Anyway, after altering the AU bytes and copying everything I had on both 128 MB MFM emulator images to it, reported available disk space looks plausible; some 85 MB remains. So in any case, it seems I might just use this method for now and see how things turn out.

 

Could it be because, when using a SCSI2SD or ZuluSCSI, that people for obvious reasons create their images within the 248 MB limit, and thus, won't experience such issues? Using a bigger disk than what's supported could cause some issues of course.

 

One of the things I don't understand by the way, is that DU2k claims the max disk size is 260 MB, not 248... but then again, there are a lot of things I don't understand.  

 

Thanks Tim for your kind help, once again! I'll buy you a pizza, when I some day make my entry in the States. 🇺🇸

SCS1_VIB

Edited October 3 by Brufnus

[+InsaneMultitasker]

3 hours ago, Brufnus said:

So... here's a VIB dump from a freshly formatted and empty drive. If there's something I'm abundant of, it's SCA drives.  

 

Anyway, after altering the AU bytes and copying everything I had on both 128 MB MFM emulator images to it, reported available disk space looks plausible; some 85 MB remains. So in any case, it seems I might just use this method for now and see how things turn out.

 

Could it be because, when using a SCSI2SD or ZuluSCSI, that people for obvious reasons create their images within the 248 MB limit, and thus, won't experience such issues? Using a bigger disk than what's supported could cause some issues of course.

 

One of the things I don't understand by the way, is that DU2k claims the max disk size is 260 MB, not 248... but then again, there are a lot of things I don't understand.  

 

Thanks Tim for your kind help, once again! I'll buy you a pizza, when I some day make my entry in the States. 🇺🇸

SCS1_VIB 8.13 kB · 2 downloads

 

CHKDSK uses the DIR routine to determine the free and used byte values.  The calculation:  (sector count) / (4 sectors per K) * 1024 bytes/K.  

Thus, available bytes on disk is 998512 sectors / 4 * 1024 = 255619072.  This makes sense, since the DIR routine evaluates the bitmap. (It also means that CHKDSK is essentially worthless for hard drives). 

 

The below screenshot was obtained by setting the total AU word to >F410.  This is close to the edge case of 1,000,000 sectors and 256,000,000 bytes.  (Note: 256MiB not 256MB). If I set the total AU word to >F420, the total sectors and bytes are wrong.   I don't have time right now to locate the error but as best I can tell, it does not impact the file structure. 

 

To go one step further, if I set the maximum AU word to >F800 and the sector/AU byte to >7x, there is no evidence of bitmap overrun.  The total sectors does not exceed the file structure capacity.  Last year (?) we identified a bug that allowed the DSR to exceed the bitmap when the highest formatted sector was used, instead of wrapping to the start of the disk to look for open sectors.  I am fairly certain this issue was fixed but I can't find the notes to support my memories. Perhaps @9640News remembers us dealing with this. 

 

If I have time this weekend, I'll look into the calculation issue. 

 

 

 

Edited October 3 by InsaneMultitasker
MiB not KiB

[Brufnus]

2 minutes ago, InsaneMultitasker said:

 

CHKDSK uses the DIR routine to determine the free and used byte values.  The calculation:  (sector count) / (4 sectors per K) * 1024 bytes/K.  

Thus, available bytes on disk is 998512 sectors / 4 * 1024 = 255619072.  This makes sense, since the DIR routine evaluates the bitmap. (It also means that CHKDSK is essentially worthless for hard drives). 

 

The below screenshot was obtained by setting the total AU word to >F410.  This is close to the edge case of 1,000,000 sectors and 256K. If I set the total AU word to >F420, the total sectors and bytes are wrong.   I don't have time right now to locate the error but as best I can tell, it does not impact the file structure. 

 

To go one step further, if I set the maximum AU word to >F800 and the sector/AU byte to >7x, there is no evidence of bitmap overrun.  The total sectors does not exceed the file structure capacity.  Last year (?) we identified a bug that allowed the DSR to exceed the bitmap when the highest formatted sector was used, instead of wrapping to the start of the disk to look for open sectors.  I am fairly certain this issue was fixed but I can't find the notes to support my memories. Perhaps @9640News remembers us dealing with this. 

 

If I have time this weekend, I'll look into the calculation issue. 

 

 

 

Okay, this is interesting. I also noticed that GDM2k reports the total and used space incorrectly, albeit the available disk space shows up correctly. Directory Manager OTOH, shows the proper values. So these definitely determine their values in different ways.

 

Since you addressed the bitmap side of the case as well, I've reconsidered solving my problem for now by dumping a VIB from a (248 MB) MFM image, edit the volume name so that it matches, and write that one to the disk(s) after a fresh format. Then everything should add up, I guess.

 

Take your time with this, though. c",)

 

 

[+InsaneMultitasker]

1 minute ago, Brufnus said:

Directory Manager OTOH, shows the proper values. So these definitely determine their values in different ways.

Good clue.

[Brufnus]

29 minutes ago, InsaneMultitasker said:

Good clue.

Yes, perhaps that might prove useful as well. 😊 

[+9640News]

19 hours ago, InsaneMultitasker said:

 

CHKDSK uses the DIR routine to determine the free and used byte values.  The calculation:  (sector count) / (4 sectors per K) * 1024 bytes/K.  

Thus, available bytes on disk is 998512 sectors / 4 * 1024 = 255619072.  This makes sense, since the DIR routine evaluates the bitmap. (It also means that CHKDSK is essentially worthless for hard drives). 

 

The below screenshot was obtained by setting the total AU word to >F410.  This is close to the edge case of 1,000,000 sectors and 256,000,000 bytes.  (Note: 256MiB not 256MB). If I set the total AU word to >F420, the total sectors and bytes are wrong.   I don't have time right now to locate the error but as best I can tell, it does not impact the file structure. 

 

To go one step further, if I set the maximum AU word to >F800 and the sector/AU byte to >7x, there is no evidence of bitmap overrun.  The total sectors does not exceed the file structure capacity.  Last year (?) we identified a bug that allowed the DSR to exceed the bitmap when the highest formatted sector was used, instead of wrapping to the start of the disk to look for open sectors.  I am fairly certain this issue was fixed but I can't find the notes to support my memories. Perhaps @9640News remembers us dealing with this. 

 

If I have time this weekend, I'll look into the calculation issue. 

 

 

L8/GETSEC has notes on the bitmap and the last bit in the cluster allocation unit.