Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Software, Gry - 8bit » FDISK by FJC.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
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.
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.
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.
Czy tak się dzieje na każdym dysku/karcie czy tylko na jednym konkretnym?
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.
W wolnej chwili wyciągnę zatem IDEplusa i spróbuję zrobić to co opisujesz. A potem powtórzę na Side.
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.
zapytajcie autora czy przewidział taką liczbę partycji
Nie ma jakiegoś limitu na łączny rozmiar?
Draco sugerował 8GB, u mnie to 4,7, czy jakoś tak
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 :)
Yeah: this is definitely a bug. I'll look into it when I get time. Thanks for flagging it up.
po raz kolejny Pin-ek dowiódł że jego konfiguracja sprzętowo programowa jest nadzwyczaj awaryjna :)
Nach, po prostu Pinokio jest skutecznym testerem, przed którym żaden przypadek brzegowy się nie ukryje ;)
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.
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. :)
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. :)
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
}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.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Software, Gry - 8bit » FDISK by FJC.
Wygenerowano w 0.021 sekund, wykonano 66 zapytań