rozmiar bloku pliku - różnica między stat a ls

Zauważyłem, że kiedy:

ls -ls file

Zapewnia liczbę bloków, powiedzmy 8 bloków.

Kiedy robię:

stat file

Zauważam, że liczba bloków wynosi 16, dwa razy więcej niż podana przez ls.

Rozmiar bloku w moim systemie plików to 4096. Dowiedziałem się, że dowolna jednostka dla bloków używanych przez ls to 1024. Czy to prawda, że ​​stat używa arbitralnej jednostki 512 bajtów podczas zgłaszania bloków?

Jeśli tak, to czy istnieje przyczyna niespójności?

Używam Ubuntu 11.10 w systemie plików ext4.

Wiele dysków ma rozmiar sektora 512 bajtów, co oznacza, że ​​każdy odczyt lub zapis na dysku przenosi cały sektor 512 bajtów jednocześnie. Projektowanie systemów plików, w których sektor nie jest podzielony między pliki, jest dość naturalne (co skomplikowałoby projekt i obniżyłoby wydajność); dlatego systemy plików zwykle używają porcji 512-bajtowych. Stąd tradycyjne narzędzia, takie jak lsi duwskazują rozmiary w jednostkach po 512 bajtów.

Dla ludzi 512-bajtowe jednostki nie mają większego znaczenia. 1kB to ten sam rząd wielkości i dużo bardziej znaczący. Blok systemu plików (najmniejsza jednostka, w której plik jest podzielony) w rzeczywistości często składa się z kilku sektorów: 1kB, 2kB i 4kB to wspólne rozmiary bloków systemu plików; dlatego 512-bajtowa jednostka nie jest silnie uzasadniona projektem systemu plików i nie ma żadnego dobrego powodu poza tradycją, aby używać 512-bajtowej jednostki poza sterownikiem dysku.

Więc masz tradycję, która nie ma wiele do zrobienia i bardziej czytelną konwencję, która się nabiera. Trochę jak liczba ósemkowa i szesnastkowa: nie ma takiej, która jest poprawna, a drugiej, która jest błędna, to różne sposoby zapisywania tych samych liczb.

Wiele narzędzi ma opcję wyboru jednostek wyświetlania: ls --block-size=512dla GNU ls, ustawienie POSIXLY_CORRECT=1w środowisku GNU dfi GNU dupobierania jednostek 512-bajtowych (lub przekazywanie -kdo wymuszenia jednostek 1kB). To, co statpolecenie w GNU coreutils przedstawia jako „rozmiar bloku” ( %Bwartość), jest zależną od systemu operacyjnego wartością interfejsu wewnętrznego; w zależności od systemu operacyjnego może to być lub nie być związane z rozmiarem używanym przez system plików lub kod dysku (zwykle nie jest - zobacz Różnica między rozmiarem bloku a rozmiarem klastra ). W systemie Linux wartość wynosi 512, niezależnie od tego, co robi dowolny sterownik bazowy. Wartość %Bnigdy nie ma znaczenia, to tylko dziwactwo, że w ogóle istnieje.

Po zagłębieniu się w kod źródłowy i standard POSIX, powiedziałbym, że odpowiedź @ antje-m i @Gilles są w większości poprawne.

Warto zacytować komentarz z POSIX.1-2008 jako podsumowanie:

Wykorzystanie 512-bajtowych jednostek jest historyczną praktyką i utrzymuje zgodność z ls i innymi narzędziami w tym tomie POSIX.1-2008. Nie wymaga to, aby sam system plików był oparty na blokach 512-bajtowych. Opcja -k została dodana jako środek kompromisowy. Standardowi programiści uzgodnili, że 512 bajtów jest najlepszą jednostką domyślną ze względu na pełną historyczną spójność w Systemie V (w porównaniu do mieszanego użycia 512/1024-bajtów w systemach BSD) oraz opcję -k przełączającą się na 1024- jednostki bajtowe były dobrym kompromisem. Użytkownicy, którzy wolą bardziej logiczną 1024-bajtową liczbę, mogą łatwo zmienić alias df na df -k bez przerywania wielu historycznych skryptów opartych na jednostkach 512-bajtowych.

Dla rozmiaru bloku w ls -s:

POSIX mówi, że domyślny rozmiar bloku jest zdefiniowany w implementacji, chyba że -kpodano opcję.

Domyślny rozmiar bloku zaimplementowany w GNU coreutils lsjest zdefiniowany w GNU gnulib: gnulib/lib/human.c

/* The default block size used for output.  This number may change in
   the future as disks get larger.  */
#ifndef DEFAULT_BLOCK_SIZE
# define DEFAULT_BLOCK_SIZE 1024
#endif

który pochodzi ze starego zatwierdzenia:

commit 96e78d1f64d7c8d2acc5ad27dc3e73b96ae80585
Author: Jim Meyering <[email protected]>
Date:   Mon Jun 29 15:23:04 1998 +0000

Sam komunikat zatwierdzenia nie mówił nic o liczbie 1024.

I zauważ, że rozmiar bloku użyty w dui dfwynosi również 1024, lspo prostu zdecydowałem się z nimi pogodzić. Chociaż dla dui dfjest to sprzeczność ze standardem POSIX (więc tutaj POSIXLY_CORRECTpojawia się zmienna środowiskowa ). To wydaje się decyzja zespołu GNU, patrz strona Wikipedii POSIX na temat tej kontrowersji.

Dla polecenia stat.

Nie jest to część standardu POSIX, ale wywołanie systemowe to. Jednak jednostka wielkości bloku nie jest ustandaryzowana ( sys_stat.h ):stat

Jednostka dla elementu st_blocks w strukturze statystyk nie jest zdefiniowana w POSIX.1-2008.

statPolecenie po prostu wyświetla informacje dostarczone przez statwywołanie systemowe, a przy użyciu 512 rozmiar bloku z kilkoma wyjątkiem (są one non-Linux, na przykład HP-UX, IBM AIX itp widzieć makra zdefiniowane w gnulib/lib/stat-size.h).

Liczba 512 jest więc raczej historycznym wyborem i konwencją Linuksa.

GNU coreutils(Stąd lspoleceń) nie jest częścią jądra Linux (stąd statpołączeń), są one ukierunkowane na różne aspekty systemu, GNU coreutilsjest bardziej dla ludzi (łatwiejsze do odczytania) i jądro Linux dla sprzętu abstrakcyjnego (stąd bliżej do sprzętu).

Edycja: rozmiar bloku 4096 jest rozmiarem „bloku we / wy”, rzeczywisty rozmiar bloku fizycznego prawdopodobnie nadal wynosi 512 bajtów, jak wyjaśniono w tym pytaniu .

Te statpolecenia używa fizycznej rozmiar bloku na dysku twardym. Zasadniczo wszystkie dyski twarde od czasu ich powstania w 1956 r. Używały 512-bajtowych bloków. Jednak ostatnio zaczęło się to zmieniać wraz z nadchodzącym formatem zaawansowanym.

Podejrzewam, że lsrozmiar bloku 1024-bajtowego ma również przyczynę historyczną. Być może kiedyś system plików miał rozmiar bloku 1024 lub był używany, aby podać rozmiar w kilobajtach. Ale (przynajmniej z GNU coreutils) możesz określić rozmiar bloku za pomocą --block-size=opcji.