10.03.2018 08:53
[#1]
PFS3 All-In-One v3.0
Amikoledzy,
Toni Willen przygotował nową wersję pakietu PFS-AIO v3.0 naprawiający bardzo poważny i łatwy w reprodukcji błąd związany z korupcją partycji (Wrong Index Block ID) podczas z pozoru negroźnych operacji dyskowych na partycji. Zachęcam Was wszystkich na przesiadkę na właśnie tę wersję. Szczegóły poniżej:
Jakiś czas temu postanowiłem przetestować projekt HstWB, którego autorem jest Henrik Nørfjand Stengaard. Stworzyłem kilka testowych systemów - czysty 3.1, 3.9 z BB1&2, a następnie utworzyłem kilka dodatkowych dysków z partycjami na gry, dema i programy (>5GB bazujące na PFS3AIO - v2.3). W kolejnym kroku ściągnąłem gry z pakietu Retroplay 3.0 z EAB FTP i przystąpiłem do rozpakowywania. W pewnym momencie, podczas rozpakowywania gier, pojawił się monit "Wrong Index Block ID", a po restarcie pojawiy się "Disk Write Protected", "Disk Update Failed", LRU, etc. PFSDoctor v1.6 pomimo tego, iż nie jest przystosowany do działania poprawnie z partycjami powyżej 4GB, raportował po kilkaset błędów (po czym kończył swoją pracę wraz z pojawieniem się GURU). Pamiętałem, że poprawka do błędu związanego z "Wrong Index Block ID" był głównym powodem pojawienia się wersji v2.3. Niestety wkrótce po jej wydaniu pojwiły się pierwsze raporty świadczące o tym, iż ten błąd wciąż jest reprodukowalny w pewnych, nieznanych jeszcze, scenariuszach.
Zawodowa ciekawość sprawiła, że postanowiłem się temu bliżej przyjrzeć. Zgłosiłem błąd Henrikowi, a następnie napisałem bezpośrednio do Toniego i przedstawiłem mu zarys scenariusza. Kolejne dni upłyneły na szukaniu w 100% reprodukowalnego scenariusza, który były również w miarę szybki w testowaniu. Oto on (w uproszczeniu):
1. Utwórz 7GB partycję PFS3AIO (RDB, pfsformat filename size = 107 znaków, MaxTransfer = 0x1fe00).
2. Wypełnij ~6GB grami WHDLoad.
3. Rozpakuj grę Emerald Mines CD (50486 plików, 55MB).
4. Usuń folder EMCD.
5. Spróbuj rozpakować EMCD jeszcze raz w tej samej lokacji.
Później okazało się, że krok drugi jest w sumie również zbędny i ów scenariusz da się jeszcze bardziej uprościć. Po wymianie maili pomiędzy Tonim, a Michielem Peltem (oryginaly autor PFS) udało się znaleźć przyczynę. Michael przygotował 1-linijkowy fix.
"Bug was as simple as single line missing that marked super index block as modified (=it needs to be written to the disk when a transaction is committed).
It sounds very dangerous but actually, it only triggered in cases like this where a huge amount of new files/directories gets quickly created (like hundreds of them, perhaps even thousands).
In normal case modified (but not marked as modified) new index block stays in internal memory cache and when pfs3 commits the transaction (in few seconds or so), it updates any index blocks, and as long as modified but not marked as a modified block is still in cache, it gets written back to the disk and everything is fine.
The problem only triggers when newly accessed blocks get created so quickly that cache becomes full, replacing all old unneeded data with new blocks before transaction commit. When commit time comes, a modified block isn't in cache so it is loaded from disk, modified and then written back. Because it was re-loaded from disk, original modifications were lost.
In other words: partition needed to be >=5G and huge amounts of relatively small files/dirs needs to be created without no pauses."
Przez ostatnie kilka dni testowałem nowe wydanie i nie udało mi się owego błędu zreprodukować, wliczając w to scenariusze, w których miałem partycje 100GB+, na których wypakowałem TOSEC. Mam nadzieję, że nowe wydanie sprawi, że wątki o utracie danych i problemach z partycjami staną się przeszłością. Zachęcam do testowania nowej wersji :)
Toni Willen przygotował nową wersję pakietu PFS-AIO v3.0 naprawiający bardzo poważny i łatwy w reprodukcji błąd związany z korupcją partycji (Wrong Index Block ID) podczas z pozoru negroźnych operacji dyskowych na partycji. Zachęcam Was wszystkich na przesiadkę na właśnie tę wersję. Szczegóły poniżej:
Jakiś czas temu postanowiłem przetestować projekt HstWB, którego autorem jest Henrik Nørfjand Stengaard. Stworzyłem kilka testowych systemów - czysty 3.1, 3.9 z BB1&2, a następnie utworzyłem kilka dodatkowych dysków z partycjami na gry, dema i programy (>5GB bazujące na PFS3AIO - v2.3). W kolejnym kroku ściągnąłem gry z pakietu Retroplay 3.0 z EAB FTP i przystąpiłem do rozpakowywania. W pewnym momencie, podczas rozpakowywania gier, pojawił się monit "Wrong Index Block ID", a po restarcie pojawiy się "Disk Write Protected", "Disk Update Failed", LRU, etc. PFSDoctor v1.6 pomimo tego, iż nie jest przystosowany do działania poprawnie z partycjami powyżej 4GB, raportował po kilkaset błędów (po czym kończył swoją pracę wraz z pojawieniem się GURU). Pamiętałem, że poprawka do błędu związanego z "Wrong Index Block ID" był głównym powodem pojawienia się wersji v2.3. Niestety wkrótce po jej wydaniu pojwiły się pierwsze raporty świadczące o tym, iż ten błąd wciąż jest reprodukowalny w pewnych, nieznanych jeszcze, scenariuszach.
Zawodowa ciekawość sprawiła, że postanowiłem się temu bliżej przyjrzeć. Zgłosiłem błąd Henrikowi, a następnie napisałem bezpośrednio do Toniego i przedstawiłem mu zarys scenariusza. Kolejne dni upłyneły na szukaniu w 100% reprodukowalnego scenariusza, który były również w miarę szybki w testowaniu. Oto on (w uproszczeniu):
1. Utwórz 7GB partycję PFS3AIO (RDB, pfsformat filename size = 107 znaków, MaxTransfer = 0x1fe00).
2. Wypełnij ~6GB grami WHDLoad.
3. Rozpakuj grę Emerald Mines CD (50486 plików, 55MB).
4. Usuń folder EMCD.
5. Spróbuj rozpakować EMCD jeszcze raz w tej samej lokacji.
Później okazało się, że krok drugi jest w sumie również zbędny i ów scenariusz da się jeszcze bardziej uprościć. Po wymianie maili pomiędzy Tonim, a Michielem Peltem (oryginaly autor PFS) udało się znaleźć przyczynę. Michael przygotował 1-linijkowy fix.
"Bug was as simple as single line missing that marked super index block as modified (=it needs to be written to the disk when a transaction is committed).
It sounds very dangerous but actually, it only triggered in cases like this where a huge amount of new files/directories gets quickly created (like hundreds of them, perhaps even thousands).
In normal case modified (but not marked as modified) new index block stays in internal memory cache and when pfs3 commits the transaction (in few seconds or so), it updates any index blocks, and as long as modified but not marked as a modified block is still in cache, it gets written back to the disk and everything is fine.
The problem only triggers when newly accessed blocks get created so quickly that cache becomes full, replacing all old unneeded data with new blocks before transaction commit. When commit time comes, a modified block isn't in cache so it is loaded from disk, modified and then written back. Because it was re-loaded from disk, original modifications were lost.
In other words: partition needed to be >=5G and huge amounts of relatively small files/dirs needs to be created without no pauses."
Przez ostatnie kilka dni testowałem nowe wydanie i nie udało mi się owego błędu zreprodukować, wliczając w to scenariusze, w których miałem partycje 100GB+, na których wypakowałem TOSEC. Mam nadzieję, że nowe wydanie sprawi, że wątki o utracie danych i problemach z partycjami staną się przeszłością. Zachęcam do testowania nowej wersji :)
11.03.2018 04:32
[#7]
Re: PFS3 All-In-One v3.0
@Tomarkus, post #1
Z tą numeracją jest trochę zamieszania. Ostatnia wersja 2.3, to wewnętrznie 18.5, a ta teraz 3.0, to 19.0. Nie wiem, dlaczego Toni o tym nie wspomina w dokumentacji.
Dobrze, że chociaż HDToolBox poprawnie identyfikuje nową wersję jako 19.0, bo 18.5 jest błędnie rozpoznawane jako 18.0.
Dobrze, że chociaż HDToolBox poprawnie identyfikuje nową wersję jako 19.0, bo 18.5 jest błędnie rozpoznawane jako 18.0.
27.03.2018 17:33
[#8]
Re: PFS3 All-In-One v3.0
@Tomarkus, post #1
Ciagle wyglada na to, ze jednak FFS ma najmniej bledow. Ciekawy blad PFS jest tutaj (post 222):
http://eab.abime.net/showthread.php?t=90778&page=12
Zle pokazywana jest zajetosc HD-ka. No i druga sprawa, 1.8 GB HD jest zjedzone przez PFS w porownaniu do FFS, a to olbrzymia ilosc. Jakies 10% prawie, bardzo niefektywne to jest. Zakladam, ze te dane sa prawidlowe.
http://eab.abime.net/showthread.php?t=90778&page=12
Zle pokazywana jest zajetosc HD-ka. No i druga sprawa, 1.8 GB HD jest zjedzone przez PFS w porownaniu do FFS, a to olbrzymia ilosc. Jakies 10% prawie, bardzo niefektywne to jest. Zakladam, ze te dane sa prawidlowe.
