Nowo utworzony system plików XFS pokazuje używane 78 GB


18

Mamy macierz RAID 6 o pojemności 12 TB, która ma zostać skonfigurowana jako pojedyncza partycja z systemem plików XFS . Podczas tworzenia nowego systemu plików mówi, że ma 78 GB w użyciu, ale na dysku nie ma żadnych plików.

[root@i00a ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         32G     0   32G   0% /dev
tmpfs            32G     0   32G   0% /dev/shm
tmpfs            32G   11M   32G   1% /run
tmpfs            32G     0   32G   0% /sys/fs/cgroup
/dev/sdb3       154G  3.9G  150G   3% /
/dev/sdb2      1014M  153M  862M  16% /boot
/dev/sdb1       599M  6.7M  593M   2% /boot/efi
/dev/sdc1       187G  1.6G  185G   1% /var
tmpfs           6.3G     0  6.3G   0% /run/user/0
/dev/sda1        11T   78G   11T   1% /export/libvirt

Czy zrobiłem coś złego? Czy to z założenia?

Wygląda na to, że dziennik systemu plików zajmuje tylko około 2 GB i nie mogę się dowiedzieć, co jeszcze może zrobić z wykorzystaniem tego miejsca.

[root@i00a ~]# xfs_info /export/libvirt/
meta-data=/dev/sda1              isize=512    agcount=11, agsize=268435455 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=2929458688, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Informacje o partycji:

[root@irb00a ~]# parted /dev/sda1
GNU Parted 3.2
Using /dev/sda1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Unknown (unknown)
Disk /dev/sda1: 12.0TB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number  Start  End     Size    File system  Flags
 1      0.00B  12.0TB  12.0TB  xfs

To jest Dell FX2 z czterema węzłami obliczeniowymi FC430 i dwoma węzłami pamięci masowej FD332 z systemem Red Hat Enterprise Linux 8 ( Ootpa ).


Czy to jest naprawdę puste? Próba reprodukcji (z obrazem 12 TB, domyślnymi ustawieniami mkfs bsize=4096 blocks=2929687500) df -hdaje wynik Size 11T, Used 12G, nie taki 78Gjak w twoim przykładzie. xfsdumpprodukuje plik
— KB

2
Ach, zauważam, że miałeś, reflink=1ale domyślnie było dla mnie reflink=0. Z reflink=1, mówi również 78Gużywane dla mnie, więc mogę to teraz odtworzyć.
— frostschutz

Wygląda na to, że jest to zgodne z projektem, ale jeśli masz pewność, że linki zwrotne nie przyniosą efektu w twoim przypadku użycia, możesz rozważyć jego wyłączenie.
— frostschutz

Nie wiem Jedyne, co tu będzie, to pliki qcow2 dla maszyn wirtualnych.
— yakatz

Wygląda na to, że niektóre narzędzia libvirt obsługują reflink, ale prawdopodobnie nie jest warte kłopotu: stackoverflow.com/a/41968000/597234 Prawdopodobnie mogę zmieścić całą dodatkową maszynę wirtualną w zaoszczędzonej przestrzeni.
— yakatz

Odpowiedzi:


2

W przypadku XFS pusty system plików „Rozmiar używany”, jak pokazano, df -hwydaje się bardzo zależeć od tego, które funkcje metadanych włączasz w danym mkfs.xfsmomencie.

Testowanie z pustym plikiem 12 TB:

# truncate -s 12TB xfstest.img

Ustawienia domyślne (w moim bieżącym systemie ArchLinux):

# mkfs.xfs xfstest.img 
meta-data=xfstest.img            isize=512    agcount=11, agsize=268435455 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=2929687500, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount -o loop xfstest.img loop/
# df -h loop/
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       11T   12G   11T   1% /dev/shm/loop
# umount loop/

Używanie reflink=1:

# mkfs.xfs -m reflink=1 -f xfstest.img
meta-data=xfstest.img            isize=512    agcount=11, agsize=268435455 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=2929687500, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount -o loop xfstest.img loop/
# df -h loop/
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       11T   78G   11T   1% /dev/shm/loop

Korzystanie crc=0, reflink=0(z jakiegoś powodu, że również okazuje finobt=0, sparse=0)

# mkfs.xfs -m reflink=0 -m crc=0 -f xfstest.img 
meta-data=xfstest.img            isize=256    agcount=11, agsize=268435455 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0, sparse=0, rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=2929687500, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mount -o loop xfstest.img loop/
# df -h loop/
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       11T   33M   11T   1% /dev/shm/loop

W skrócie:

# df -h loop/
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       11T   78G   11T   1% /dev/shm/loop (reflink=1, crc=1)
/dev/loop0       11T   12G   11T   1% /dev/shm/loop (reflink=0, crc=1)
/dev/loop0       11T   33M   11T   1% /dev/shm/loop (reflink=0, crc=0)

Tak więc „używane” miejsce w świeżym systemie plików 12 TB to 78G, 12G lub zaledwie 33M, w zależności od tego, które funkcje metadanych włączysz w czasie mkfs.


RedHat 8 ma reflinks=1domyślnie
— yakatz

24

Wszystkie systemy plików mają narzuty na swoje wewnętrzne struktury danych. Te wewnętrzne informacje są wykorzystywane przez system plików do tworzenia plików i katalogów w przyszłości oraz do śledzenia, gdzie wszystko jest przydzielone. Te dane są łącznie nazywane „metadanymi”. To dane „o” danych w systemie plików. Metadane są traktowane jako narzut, ponieważ zajmują miejsce, ale nie są danymi użytkownika. Narzut ten jest nieuniknionym efektem ubocznym korzystania z dowolnego systemu plików.

Zgodnie z tym postem na blogu XFS ma narzut wynoszący około 0,5% całkowitego miejsca na dysku. (Pamiętaj, że ten post pochodzi z 2009 r., Ale nie ma powodu, aby to drastycznie zmienić). Uzyskał ten wynik, testując obciążenie systemu plików z kilkunastu różnych systemów plików guestfish.

0,5% twojego miejsca na 12 TB to 60 GB, więc wydaje się, że jest to dość zbliżone do oczekiwanego użycia. Podejrzewam, że jego liczba powinna być nieco wyższa niż 0,5%, ale że była zaokrąglona.


9
Warto zauważyć, że niektóre systemy plików zgłaszają pełny przydzielony rozmiar, a następnie obciążają księgowość za zajęte miejsce, podczas gdy inne odejmują księgowanie od pełnego rozmiaru i zgłaszają tylko przestrzeń plików jako „używane”.
— Chrylis -on strike-

3
Obciążenie systemu plików ... sprawiając, że ludzie pytają, dlaczego ich dyski twarde nie zgłaszają tego, co jest na naklejce od 1983 roku.
— J ...

3
@J ... Właściwie dysk twardy często sprzedaje tam rozmiar, używając 1 GB = 1000 MB zamiast 1024 MB. Tak więc HD sprzedawany w 512 GB jest w rzeczywistości o 12 GB mniejszy niż podany rozmiar. Z TB jest jeszcze gorzej, ponieważ używają 1 TB = 1000 GB = 1000 * 1000 MB. 1 TB HD to tak naprawdę 976 GB zamiast 1024 GB. Ogromne 48 GB utracone przez TB.
— Justin Lessard

4
Różnica w pomiarze gigabajtów (baza 10) w porównaniu do gibibajtów (baza 2) nie jest wyświetlana jako zajęte miejsce df.
— yakatz

1
@JustinLessard Zapomniałeś o narzutach na poziomach MiB i KiB. Dysk twardy 512 GB jest w rzeczywistości o ponad 32 GiB mniejszy niż prawdziwy dysk 512 GiB. Co więcej, dysk o pojemności 1 TB jest naprawdę bardziej podobny do 0,909 TiB, gdy uwzględnia się koszty ogólne TiB, GiB, MiB i KiB. (1 * 1000 ^ 4/1024 ^ 4) = 0,90949
— pingwin359
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.