Re: Sprawdzanie dysku przy starcie

Autor: Michal Kawecki <kkwinto_at_o2.px>
Data: Fri 15 Dec 2006 - 07:03:29 MET
Message-ID: <6sdtle.oic.ln@kwinto.prv>
Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original

"Lawrens Hammond" <valhalla@interia.pl> wrote in message
news:4581da5a$1@news.home.net.pl...
> Użytkownik "Michal Kawecki" <kkwinto@o2.px> napisał w wiadomości
> news:m03sle.u65.ln@kwinto.prv...
>
>> Bo poza partycją znajduje się na przykład newralgiczny obszar EMBR
>> (blisko
>> 64 kB) na początku dysku, tudzież pusta końcówka dysku - czyli jego
> ostatnia
>> niepełna ścieżka, której Windows zwyczajowo nie zajmuje pod partycję.
>
> Na upartego da się tam wcisnąć całość, robiłem to z powodzeniem.

Jasne, ale dla Windows i większości programów narzędziowych będzie to zawsze
traktowane jako błąd w tabeli partycji.

>> > Zresztą i tak linia NT literki ma "wirtualnie" chyba... Dla zgodności?
>>
>> Na pierwszy rzut oka wydawałoby się że literki to kiepski pomysł, ale jak
>> się bliżej zastanowić, to numerowanie partycji wcale nie jest lepsze.
>> Wystarczy że zmieni się kolejność partycji w MBR dysku i całą numerację
> też
>> szlag trafia.
>
> A w Linuxie?

No właśnie mam na myśli Linuksa, bo to tam jest stosowana numeracja partycji
zamiast literek. Są co prawda pewnie metody pozwalające uniknąć tego efektu,
ZTCP na przykład partycje XFS mają wewnętrzny unikalny znacznik pozwalający
na jednoznaczne zidentyfikowanie takiej partycji niezależnie od jej
położenia na dysku, ale jest to przydatne tylko dla uruchomionego systemu.
Dla programów narzędziowych jak np. dla cfdisk, który opiera się na tabeli
partycji, już nie. W Windows też istnieje alternatywa dla tabeli partycji, w
postaci dysków dynamicznych. ZTCP tam ten problem w ogóle już nie istnieje,
wolumin dynamiczny może znajdować się gdziekolwiek, może być pocięty na
kawałki albo rozrzucony po kilku dyskach, a system i tak będzie potrafił go
prawidłowo podmontować i obsłużyć.

-- 
M.   [MS-MVP]
/odpowiadając zmień px na pl/ 
Received on Fri Dec 15 07:10:08 2006

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Fri 15 Dec 2006 - 07:42:03 MET