1

Temat: FDISK by FJC.

Namierzyłem pewien dość krytyczny problem, dotyczy on programu FDISK (FJC) którym najczęściej robicie sobie partycje na urządzeniach side 1/2/3, IDE Plus i Bóg wie na czym jeszcze. Najpierw pytanie - jaki obszar dysku macie podzielony na partyje, oraz ile partycji macie w ramach jednego dysku.

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

2

Odp: FDISK by FJC.

Ja operuję na dyskach (kartach) max. 4GB, z czego na partycje atarowskie idzie tak góra z 20%. Głównie dlatego, że przy partycji 32MB i tak jest ich o wiele za dużo (literek brakuje) a i tak używam raptem kilku. Nie oszukuję się, że to moje używanie jest jakoś mocno skomplikowane.

Pamięć studenta ma charakter kwantowy - student wie wszystko, ale jednocześnie nic nie pamięta.
- Kilka(naście?) pudełek z klawiszami i światełkami. I jeden Vectrex, żeby nimi wszystkimi rządzić.

3

Odp: FDISK by FJC.

Ja mam inną sytuację, jedna partycja FAT16 2GB i 74 partycje 32MB (APT) i 2 16MB (APT).

Sytuacja krytyczna występuje u mnie w momencie dodania 78 partycji - następuje uszkodzenie danych w MBR i prawie (!) każdy zapis tablicy z tą ilością wpisów uszkadza MBR wpisując na początek MBR dość powtarzalne śmieci i zerując resztę sektora.

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

4

Odp: FDISK by FJC.

Czy tak się dzieje na każdym dysku/karcie czy tylko na jednym konkretnym?

Pamięć studenta ma charakter kwantowy - student wie wszystko, ale jednocześnie nic nie pamięta.
- Kilka(naście?) pudełek z klawiszami i światełkami. I jeden Vectrex, żeby nimi wszystkimi rządzić.

5

Odp: FDISK by FJC.

u mnie:

na 4 dyskach i dwóch komputerach, wspólny mianownik ten sam ideplus.

Wygląda to tak, że po wpisaniu 78 partycji jeśli zapiszesz to na dysk to owszem, wpis w APT jest ale dodatkowo 4 bajty z nagłówka partycji APT ląduje w pierwszych 4 bajtach MBR, reszta MBR zostaje wyzerowana i dysk jest "martwy". Miałem kopię MBR więc sobie to odtwarzałem (EDDY) aż znalazłem źródło problemu.

Ostatnio edytowany przez Pin (2022-01-10 11:17:03)

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

6

Odp: FDISK by FJC.

W wolnej chwili wyciągnę zatem IDEplusa i spróbuję zrobić to co opisujesz. A potem powtórzę na Side.

Pamięć studenta ma charakter kwantowy - student wie wszystko, ale jednocześnie nic nie pamięta.
- Kilka(naście?) pudełek z klawiszami i światełkami. I jeden Vectrex, żeby nimi wszystkimi rządzić.

7

Odp: FDISK by FJC.

Dzięki.

2GB external fat16
77 partycji apt po 32MB powiedzmy

... i zapisz tablicę, zamknij urządzenie i otwórz. Czasem nie wywala od razu, to powtórz, albo dodaj jeszcze jedną partycję zapisz i zobacz. Miej w odwodzie jakieś sio2sd z eddy i zobacz wówczas do mbr.

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

8

Odp: FDISK by FJC.

zapytajcie autora czy przewidział taką liczbę partycji

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

9

Odp: FDISK by FJC.

Przewidywał 128.

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

10

Odp: FDISK by FJC.

Nie ma jakiegoś limitu na łączny rozmiar?

Pamięć studenta ma charakter kwantowy - student wie wszystko, ale jednocześnie nic nie pamięta.
- Kilka(naście?) pudełek z klawiszami i światełkami. I jeden Vectrex, żeby nimi wszystkimi rządzić.

11

Odp: FDISK by FJC.

Draco sugerował 8GB, u mnie to 4,7, czy jakoś tak

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

12

Odp: FDISK by FJC.

Kolega @bugz_ zreplikował problem, co ciekawe występuje wyłącznie przy 78 partycjach. Jeśli przy 77 dopiszemy dwie to ponoć problemu już nie ma. Ciekawe :)

ADRES: pin@atari.pl - konto zlikwidowane. Aktualny adres: pin(at)atari8.info

13

Odp: FDISK by FJC.

Yeah: this is definitely a bug. I'll look into it when I get time. Thanks for flagging it up.

14

Odp: FDISK by FJC.

po raz kolejny Pin-ek dowiódł że jego konfiguracja sprzętowo programowa jest nadzwyczaj awaryjna :)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

15

Odp: FDISK by FJC.

Nach, po prostu Pinokio jest skutecznym testerem, przed którym żaden przypadek brzegowy się nie ukryje ;)

grzybson/SSG

16

Odp: FDISK by FJC.

flashjazzcat napisał/a:

Yeah: this is definitely a bug. I'll look into it when I get time. Thanks for flagging it up.

I was able to reproduce issue originally posted by @Pin and can give you some more insights. MBR gets corrupted when final number of created partitions is exactly 16, 47, 78 etc. Partition size doesn't matter .
This patterns seems to correlate with maximum number of partitions which one can create in one sector. First number seems to not match my theory but first APT partition has also 15 mapping slots which makes theory plausible.
I read APT_spec and create small python script for disk analysis if you would be interested. It helped me identify that issue.
If you would need any help on that just ping me.

17

Odp: FDISK by FJC.

bugz_ napisał/a:

I was able to reproduce issue originally posted by @Pin and can give you some more insights. MBR gets corrupted when final number of created partitions is exactly 16, 47, 78 etc. Partition size doesn't matter.

This is most useful information; I was trying to recognise some such pattern yesterday when testing, and I was able to corrupt the MBR when the number of partitions was exactly 78. But if I used 'fill/divide' to simply create 100 partitions, there was no problem at all. So it seems that the TOTAL number of partitions must equal one of these 'magic' values, exactly as you say.

This patterns seems to correlate with maximum number of partitions which one can create in one sector. First number seems to not match my theory but first APT partition has also 15 mapping slots which makes theory plausible.

Good observation. What with my distracted mental state recently, I spent a few seconds trying to correlate the numbers with the various sector boundaries in the APT chain, but totally forgot while doing so that sector 1 of the chain is special, in that it contains the mapping slots in the first 256 bytes, and therefore only 16 partition table entries (in the upper half). Now, it starts to make sense.

I read APT_spec and create small python script for disk analysis if you would be interested. It helped me identify that issue.
If you would need any help on that just ping me.

Again - this would be most helpful. I may well get in touch, although I did (years ago) write an A8-based utility which dumps the entire APT record chain with absolute sector numbers, etc. It might be a lot more expedient to use a PC-hosted tool, however. Naturally the partition editor is burdened with complexity and eligible for many re-writes when I get time (I now dislike the mandate that all partitions are kept contiguous), and I have not done any serious work on it for some years.

The other interesting thing is that we had an issue just like this in the past, and I addressed it, fixed the primary fault, but yet a problem persists (coming to light literally years later). In any case, thanks to your analysis, I have some clues now. :)

18

Odp: FDISK by FJC.

Found the bug. An extra (non-existent) entry from the table of LBA partition table sector numbers was being grabbed from the array when the last partition was at the end of a sector of the APT chain. Since the bug resulted in MBR corruption, it seemed a good idea to add debugging code which triggered a breakpoint if any attempt was made to write sector 0 when laying out the APT. The breakpoint was immediately triggered with 78 partitions...

Please try the version attached and let me know if it passes Pin's most extreme stress-tests. :)

Post's attachments

fdisk.xex 22.43 kb, liczba pobrań: 2 (od 2022-01-16) 

Tylko zalogowani mogą pobierać załączniki.

19

Odp: FDISK by FJC.

flashjazzcat napisał/a:

Found the bug. An extra (non-existent) entry from the table of LBA partition table sector numbers was being grabbed from the array when the last partition was at the end of a sector of the APT chain. Since the bug resulted in MBR corruption, it seemed a good idea to add debugging code which triggered a breakpoint if any attempt was made to write sector 0 when laying out the APT. The breakpoint was immediately triggered with 78 partitions...

Please try the version attached and let me know if it passes Pin's most extreme stress-tests. :)

17 partitions created

Reading MBR from example_disk.img starting at sector 0 (0) [0]
parent: 0 partition data: 446-462, type: FAT32, LBA
parent: 0 partition data: 462-478, type: APT, Atari Partition Table
Reading 512 bytes from sector 0x40003F (4194367) [0x80007e00 (2147515904)]
Found APT partition at sector 0x40003F (4194367)
Reading 512 bytes from sector 0x400690 (4195984) [0x800d2000 (2148343808)]
Found APT partition at sector 0x400690 (4195984)
55AA
b'APT' 0 32 0x400690 0x0
mapping_slots:
{}
partitions:
{0:             67,  0,   0x400041 (     4194369 bytes),       0x64 (         100 bytes),  0, 64
, 1:             67,  0,   0x4000a6 (     4194470 bytes),       0x64 (         100 bytes),  0, 64
, 2:            67,  0,   0x40010b (     4194571 bytes),       0x64 (         100 bytes),  0, 64
, 3:            67,  0,   0x400170 (     4194672 bytes),       0x64 (         100 bytes),  0, 64
, 4:            67,  0,   0x4001d5 (     4194773 bytes),       0x64 (         100 bytes),  0, 64
, 5:            67,  0,   0x40023a (     4194874 bytes),       0x64 (         100 bytes),  0, 64
, 6:            67,  0,   0x40029f (     4194975 bytes),       0x64 (         100 bytes),  0, 64
, 7:            67,  0,   0x400304 (     4195076 bytes),       0x64 (         100 bytes),  0, 64
, 8:            67,  0,   0x400369 (     4195177 bytes),       0x64 (         100 bytes),  0, 64
, 9:            67,  0,   0x4003ce (     4195278 bytes),       0x64 (         100 bytes),  0, 64
, 10:           67,  0,   0x400433 (     4195379 bytes),       0x64 (         100 bytes),  0, 64
, 11:           67,  0,   0x400498 (     4195480 bytes),       0x64 (         100 bytes),  0, 64
, 12:           67,  0,   0x4004fd (     4195581 bytes),       0x64 (         100 bytes),  0, 64
, 13:           67,  0,   0x400562 (     4195682 bytes),       0x64 (         100 bytes),  0, 64
, 14:           67,  0,   0x4005c7 (     4195783 bytes),       0x64 (         100 bytes),  0, 64
, 15:           67,  0,   0x40062c (     4195884 bytes),       0x64 (         100 bytes),  0, 64
}
b'APT' 0 2 0x0 0x40003f
mapping_slots:
{}
partitions:
{1:             67,  0,   0x400692 (     4195986 bytes),       0x64 (         100 bytes),  0, 64
}

one deleted and looks good

Reading MBR from example_disk.img starting at sector 0 (0) [0]
parent: 0 partition data: 446-462, type: FAT32, LBA
parent: 0 partition data: 462-478, type: APT, Atari Partition Table
Reading 512 bytes from sector 0x40003F (4194367) [0x80007e00 (2147515904)]
Found APT partition at sector 0x40003F (4194367)
55AA
b'APT' 0 32 0x0 0x0
mapping_slots:
{}
partitions:
{0:             67,  0,   0x400041 (     4194369 bytes),       0x64 (         100 bytes),  0, 64
, 1:             67,  0,   0x4000a6 (     4194470 bytes),       0x64 (         100 bytes),  0, 64
, 2:            67,  0,   0x40010b (     4194571 bytes),       0x64 (         100 bytes),  0, 64
, 3:            67,  0,   0x400170 (     4194672 bytes),       0x64 (         100 bytes),  0, 64
, 4:            67,  0,   0x4001d5 (     4194773 bytes),       0x64 (         100 bytes),  0, 64
, 5:            67,  0,   0x40023a (     4194874 bytes),       0x64 (         100 bytes),  0, 64
, 6:            67,  0,   0x40029f (     4194975 bytes),       0x64 (         100 bytes),  0, 64
, 7:            67,  0,   0x400304 (     4195076 bytes),       0x64 (         100 bytes),  0, 64
, 8:            67,  0,   0x400369 (     4195177 bytes),       0x64 (         100 bytes),  0, 64
, 9:            67,  0,   0x4003ce (     4195278 bytes),       0x64 (         100 bytes),  0, 64
, 10:           67,  0,   0x400433 (     4195379 bytes),       0x64 (         100 bytes),  0, 64
, 11:           67,  0,   0x400498 (     4195480 bytes),       0x64 (         100 bytes),  0, 64
, 12:           67,  0,   0x4004fd (     4195581 bytes),       0x64 (         100 bytes),  0, 64
, 13:           67,  0,   0x400562 (     4195682 bytes),       0x64 (         100 bytes),  0, 64
, 14:           67,  0,   0x4005c7 (     4195783 bytes),       0x64 (         100 bytes),  0, 64
, 15:           67,  0,   0x40062c (     4195884 bytes),       0x64 (         100 bytes),  0, 64
}

Ostatnio edytowany przez bugz_ (Dzisiaj 18:56:41)

20

Odp: FDISK by FJC.

Great - thank you!

If this looks reliable in a few days, I will update the CAR files at the DLT permalink, and add the updated copy to the APT toolkit disk.