Jak mogę dowiedzieć się, gdzie plik fizycznie znajduje się na dysku (numery bloków)?

10

To niejasne pytanie, wiem. Próbuję przeprowadzić testy wydajności niektórych dysków na komputerze z systemem Linux. Otrzymuję niespójne wyniki, uruchamiając ten sam test na tym samym dysku. Wiem, że dyski mają różną wydajność w zależności od tego, do której części dysku jest uzyskiwany dostęp. W szczególności, odczyty i zapisy na zewnątrz dysku mają znacznie większą przepustowość niż odczyty i zapisy do wewnętrznej części dysku, ze względu na prawie stałą gęstość danych i stałą prędkość obrotową.

Chciałbym sprawdzić, czy moje niespójności można przypisać tej indukowanej geometrią wariancji przepustowości. Czy za pomocą istniejących narzędzi można dowiedzieć się, gdzie na dysku został umieszczony plik?

Jeśli nie, przypuszczam, że mogę napisać coś do bezpośredniego wyszukiwania, odczytu i zapisu do samego pliku urządzenia, omijając (i niszcząc) system plików, ale mam nadzieję tego uniknąć. Obecnie używam ext4 na jądrze 3.0 (Arch Linux, jeśli ma to znaczenie), ale interesują mnie również techniki dla innych systemów plików.

— Rick Koshi
źródło

1

kto mówi, że pliki są w jednym miejscu? Jeśli zostaną rozdrobnione (co zwykle robią), mogą skończyć na wszystkich.

— Sirex,

Absolutnie. Ale wciąż są gdzieś :-) A w moim szczególnym przypadku, pisząc pliki do nowo utworzonego systemu plików, najprawdopodobniej będą (przeważnie) niefragmentowane.

— Rick Koshi,

Nie możesz tego zrobić. Najlepsze, co możesz uzyskać, to numery bloków plików LBA, które niekoniecznie odpowiadają określonym fizycznym lokalizacjom (przynajmniej nie w sposób, który można określić, ponieważ dyski nie publikują tego mapowania). Są też inne rzeczy, na przykład bloki 3-5 mogą być kolejno ponumerowane, ale 4 mogły zostać przeniesione do zupełnie innej lokalizacji na dysku, ponieważ pierwotny sektor o wartości 4 został fizycznie uszkodzony itp. Nie można uzyskać informacji szukasz, chyba że producent napędu jest gotów podać szczegółowe dane adresowe.

— Jason C

7

Możesz użyć debugfsdo tego:

debugfs -R "stat ~/myfile" /dev/hda1

Zmień odpowiednio dysk twardy / partycję i upewnij się, że dysk jest odmontowany. Otrzymasz listę wszystkich użytych bloków:

BLOCKS:
(0):1643532
TOTAL: 1

— Bart De Vos
źródło

1

To jest idealne, dzięki. Nie jestem jednak pewien, dlaczego powiedziałeś, aby upewnić się, że dysk nie jest zamontowany. Według strony podręcznika debugfs otwiera się domyślnie w trybie tylko do odczytu, więc to polecenie powinno być całkowicie bezpieczne, nawet w aktywnym systemie plików. Oczywiście może to dawać wątpliwe wyniki, jeśli plik, którego dotyczy zapytanie, jest w tym czasie aktywnie zmieniany, ale oczywiście nie powinny powodować innych problemów. Czy coś przeoczyłem?

— Rick Koshi,

Nie, masz rację. To bardziej „najlepsza praktyka” niż konieczność. Jeśli robisz to na aktywnym systemie plików, pliki mogą się zmienić itp.

— Bart De Vos

1

Numer bloku LBA nie mówi, gdzie plik znajduje się fizycznie na dysku. Obecnie konwersja z LBA do fizycznej lokalizacji jest zasadniczo niemożliwa, ze względu na złożoność fizycznej geometrii współczesnych napędów, realokacji sektorów za kulisami itp. Ogólnie mówiąc, zwykle jest to bezpieczny zakład, że dla nośników dyskowych niższe LBA są skierowane na zewnątrz dysku, ale to tylko dlatego, że ten układ był typowy w przeszłości, już za dni adresowania CHS. Nowoczesne dyski już nawet nie publikują prawdziwej geometrii CHS, ponieważ nie mogą.

— Jason C

co z systemami tłuszczowymi?

— dashy

10

Możesz użyć FIBMAP ioctl , jak tutaj zilustrowano , lub używając hdparm :

/ $ sudo /sbin/hdparm --fibmap /etc/X11/xorg.conf

/etc/X11/xorg.conf:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    1579088    1579095          8

— Francois G.
źródło

Niestety, żadne dane wyjściowe statystyk nie są potrzebnymi informacjami. Rozmiar w bajtach i blokach, liczba i-węzłów, uprawnienia ... Żaden z nich nie odzwierciedla, które bloki zawierają dane pliku. Na przykład wszystkie moje pliki testowe (które są tego samego rozmiaru) pokazują dokładnie te same dane, z wyjątkiem numeru i-węzła i czasów dostępu / modyfikacji.

— Rick Koshi,

Tak, masz rację, przepraszam, nie czytałem poprawnie. Zmieniłem odpowiedź na stg bardziej odpowiednią.

— Francois G

hdparm rzeczywiście daje mi to, czego potrzebuję, w nieco bardziej czytelnym formacie niż debugfs. Musiałem jednak go znaleźć, ponieważ domyślnie nie jest zainstalowany (w Arch Linux). debugfs jest częścią e2fsprogs (ten sam pakiet, który daje nam mkfs i fsck), więc jest instalowany domyślnie.

— Rick Koshi,

LBA nie mówi ci, gdzie plik znajduje się fizycznie na dysku. Nie jest możliwe uzyskanie informacji o faktycznym fizycznym mapowaniu LBA.

— Jason C

Dostaję to na tłuszczu:HDIO_GETGEO failed: Inappropriate ioctl for device

— dashy

5

Ten wątek może dać ci wgląd w algorytm umieszczania plików ext4.

debugfsma bmapfunkcję, która wydaje się dawać pożądane dane. Powinieneś być w stanie podać kolejne bloki pliku i uzyskać fizyczne numery bloków.

— Paweł Brodacki
źródło

1

Dzięki za wskaźnik do wątku na temat umieszczania plików ext4. To było pouczające. :-)

— Rick Koshi,

LBA nie mówi ci, gdzie plik znajduje się fizycznie na dysku. Nie jest możliwe uzyskanie informacji o faktycznym fizycznym mapowaniu LBA.

— Jason C

2

Pytanie jest dość stare, ale istnieje inna odpowiedź, która może być przydatna dla osób, które znajdą to w Google: filefrag(w Debianie jest w pakiecie e2fsprogs).

# filefrag -eX /usr/bin/aptitude
Filesystem type is: ef53
File size of /usr/bin/aptitude is 4261400 (1041 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     1fa:    15bd805..   15bd9ff:    1fb:            
   1:      1fb..     3f2:    15c6608..   15c67ff:    1f8:    15bda00:
   2:      3f3..     410:    15c8680..   15c869d:     1e:    15c6800: last,eof
/usr/bin/aptitude: 3 extents found

Ma tę zaletę, że działa również na innych systemach plików (użyłem go do UDF), które nie wydają się być obsługiwane przez inne narzędzia tutaj opisane.

Przesunięcie przedstawione na wyjściu ma być wielokrotnością rozmiaru bloku zapisanego w drugim wierszu (tutaj 4096). Uwaga: przesunięcia logiczne mogą nie być ciągłe, ponieważ w pliku mogą znajdować się dziury (jeśli są obsługiwane przez system plików).

— Giovanni Mascellani
źródło