Użytkownik "Olek" <olotestSPAMFE@poczta.onet.pl> napisał w wiadomości
news:5c4337b1$0$501$65785112@news.neostrada.pl...
Jednakże też nauczony doświadczeniem, unikałbym takiego manewru online...
BTW. Czy EXT4 obsługuje (de)kompresję w locie? O "extenty" nie pytam,
Dla całego systemu EXT4 to chyba nie, ale nie zgłębiałem. Natomiast można
włączyć kompresję poszczególnym plikom.
No, tak w NTFS jest. Kompresja całowoluminowa była stosowana wcześniej, na
woluminach FAT16 (tylko...), gdzie tworzony był plik "emulujący" zwykły
wolumin, a (de)kompresję załatwiał już sterownik nadrzędny. Na woluminie
HOST teoretycznie siedział tylko IO.SYS, jako inicjujący wczytywanie,
MSDOS.SYS z ustawieniami (nie mylić z MSDOS.SYS z wcześniejszych wersji
DOS), COMMAND.COM wiadomo po co, choć w DOSach bodajżże od 7 wzwyż, był to
plik EXE, DRVSPACE.BIN/DBLSPACE.BIN (zależy od wersji DOS), stanowiący
sterownik woluminu, tak w skrócie.
Natomiast ZFS i BTRFS to owszem, a nawet deduplikację robią.
Ale to już raczej nie sam FS deduplikuje, lecz jego sterownik/inne narzędzie
(niekoniecznie) w tle. Pewnie jak bym się sprężył, zaszzyłbym deduplikację
wprost w systemie operacyjnym, dla FAT na którym to FS siedzi.
NTFS nie ma z nimi najmniejszego problemu, w pełni je obsługując, w końcu
jest zgodny z POSIX. Jeszcze ACL (BTRFS chyba to ma, któryś z Unixowych w
każdym razie), oraz rozszerzony zestaw atrybutów, (jak i plików)
rezydentnych i zwykłych.
Extended attributes i ACL używam na EXT4.
Się chwali, że jest. Jednak standardowe drwxrwxrwx to przeżytek. A skoro
NTFS i (nie tylko) to potrafi, a także jeszcze, to błędem jest nie
skorzystać z tego. Czy to NTFS, FAT, BTRFS, EXT, inny ch...członek.
Jeszcze o jedno zahaczę? Ale bardziej z ciekawości - ile jednocześnie
plików, może EXT4, przechować W JEDNYM "clusterze"? :) No, zapomniałem o
strumieniach i ich strukturze hierarchicznej... (taki plik kroniki jest
przykładem strumienia - "podkatalogu"/"podpliku"). "Gupi" Notatnik
potrafi swą treść zapisać w podstrumieniu, można poćwiczyć.
Eee, a takie używanie filesystemu nie jest karalne? :P
Nie, dlaczego?
Zresztą, strumienie nie są wyłączną domeną NTFS. W dużym uproszczeniu, ta
właściwość, to inna reprezentacja struktury (pod)katalogów, a w NTFS
wszystko jest plikiem, nawet urządzenia, dokładnie odwrotnie jest w
Commodore, tam wszystko jest urządzeniem, z kanałem transmisji danych i
plikami włącznie, tak upraszczając.
Co do więcej, niż 1 pliku w jednym bloku/"clusterze", odpowiedź jest
prosta - wpis $MFT zajmuje 1 kB, a przeciętną wielkością bloku jest w NTFS 4
kB. Małe pliki, mnie się udało stwierdzić, że do 768 bajtów, często siedzą
bezpośrednio we wpisie $MFT (czyli nawet plik w pliku, albowiem $MFT, prócz
tego, że jest metastrukturą, jest też po prostu plikiem, który zresztą
zawiera sam w sobie wpis/opis samego siebie). Jako, ze taki spis, to 1 kB, a
"cluster", to 4 kB, rachunek jest prosty, w jednym bloku, mogą legalnie
siedzieć 4 pliki (to można zmienić, zmieniając wielkość wpisy MFT i wielkość
"klustera").
W FAT przeszkadza mi głównie bajzel powstający przy zmianie czasu letniego
na zimowy, ale niedługo "przyjdzie walec i wyrówna", mam nadzieję i
problem zniknie sam.
Jakoś sam nie mam z tym problemu, dopóli nie przeskoczę z Win na Lin, a
potem z powrotem. Wtedy potrafi się pokomplikować, ale nigdy nie miałem
problemu z dostępen do danych, a jedynie z ich atrybutami czasowymi.
E, nieprawidłowo zamknięty system plików sam się nie naprawi. Winda
naprawia NTFS tylko się tym nie chwali.
Jakby naprawiał, to by było to widać. Jak w MFT jest kilkaset tysiecy
wpisów, KAŻDY jest sprawdzany, to to potrwa, nie sposób nie zauważyć. MFT
jest znacznie odporniejszy na błędy, niż FAT, acz ma też wobc niego i słabe
strony, ale rzadko to łapie.
Musi jeszzcze wykryś, że zaistniała potrzeba naprawy. ZTCW, po zachowaniu
systemu, przy starcie (i chyyyba przy zamykaniu, ale tu już nie jestem
pewien) jest na początku ustawiany bit "dirty", w MBR OIDP, kasowany po
zakończeniu procesu (tużz przed zamknięciem). Jeśli z jakiegoś powodu proces
zostanie przerwany, kasacja bitu "dirty" nie nastąpi i przy kolejnym starcie
system plików pójdzie do naprawy.
powód takiej sytuacji, zasadniczo, nie robiłbym tego nawet przy
najmocniejszym FS, gdyż nie mam pewności, że za którymś razem nie
strzzeli mi w jakiś istotny wektor, istotny indeks, węzeł, dowiązanie,
itd. A miałem już w rękach tak strzelone woluminy.
Najciekawiej się robi gdy zaczynasz naprawiać system plików na uszkodzonym
fizycznie urządzeniu :-)
Aaaach!!! :DDD
Jak wiadomo, fizycznie uszkodzony dysk, to ostatnie miejsce, gdzie należy
pisać cokolwiek. COKOLWIEK, zwłaszcza, ze takiego nawet zwykły odczyt
potrafi zabić, jeżeli mocniej szarpnie pozycjonerem głowic. Stąd najpierw
obrazek, potem, jak miejsce jest, to i jego kopia, DOPIERO WTEDY wszelakie
próby odzysku. A zabawa zz fizyczną próbą odzysku ze spadaczonego HDD,
zostawiam sobie, jak już dane są zabezpieczone.
Możze, gdyby to był FS, specjalnie zaprojektowany, że "komp będzie
wyłączany, nagle resetowany, branzlowany", itd., bez uprzedniego
zamkniecia systemu, to wtedy odważyłbym się na ryzyko upitolenia indeksu,
czy ciagu alokacji... Czy czego bądź, bo akurat pisało na dysk...
Znowu te Twoje perwersje :P
Bo jednak gwoździa, wolałbym wbijać młotkiem, choć pewnie mniejsze da się i
obcęgami :) (A co, nikt tego nigdy nie robił?) :))
Na poważnie - lata obserwacji. Już w latach 90. (prawie ćwierć wieku nazad)
bawiłem się w pierwsze odzyski/uzdatniania spadaczonych dysków. Niekiedy z
sukcesami, dyski nawet kilka lat chodziły, choć nie były już pewne. Ale np.
Temp.I.Files było akurat, nawet, jak coś jęknęło, to inne miejsca byly OK i
chodziło.
Poza tym też, spadaczone prawie kompletnie lubię dorżnąć, aby spadaczyć je
całkowicie :) Jak są oporne, to bywa, żże zdejmuję dekielek i wachluję się
chodzącym pozycjonerem :)
--
Łapy, łapy, cztery łapy,
A na łapach pies kudłaty.
Kto dogoni psa? Kto dogoni psa?
Może ty? Może ty? Może jednak ja...?
|