Forum Debian Users Gang

Niestety limits.conf nie pomoże, bo pozwala jedynie na ustawienie maksymalnego rozmiaru pliku. Quota w większości systemu plików linuksowych działa na poziomie partycji, wyjątek to glusterfs i chyba xfs. gdzie można ustawić limity dla poszczególnych katalogów.

Obejściem Twojego problemu jest stworzenie pliku-partycji o rozmiarze 10GB, utworzenie na nim systemu plików i zamontowanie poprzez loop w /home/user/dane.

Najprościej to chyba tak:

man dd

Nic nie wydzielasz... Tworzysz plik 10GB:

dd if=/dev/zero of=/home/plikopartycja_dane count=10 bs=1G

Tworzysz na niej system plików:

mkfs.ext4 (lub inny system plików) /home/plikopartycja_dane

montujesz:

mount -o loop /home/plikopartycja_dane /home/dane

dopisujesz odpowiednią linię do /etc/fstab

Fajny bajer. xD

admetus napisał(-a):

Na tym forum przydałoby się kilka osób, które orientują się co się w świecie linuksa dzieje. Microsoftowych speców od linuksa tu pełno, jak i ich bzdzianych kuzynów.

Szkoda się udzielić, to jak mówienie do ściany. Ci bardziej ogarnięci sami znajdą tego co chcą. Przykład tych drugich bym poprosił bo mnie to zainteresowało.

Po testach tego rozrzedzonego pliku, doszedłem do wniosku, że on kompletnie jest nie do użytku na dyskach HDD. Tak wygląda zapisanie 600M w tym pliku sparse, na którym został utworzony ext4. Dodam, że partycja ma 30G a zajętych było 5G, plik sparse ma 10G.

# filefrag -v "/media/Grafi/sparse-file"
Filesystem type is: ef53
File size of /media/Grafi/sparse-file is 10737418240 (2621440 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..    1032:      36864..     37896:   1033:
   1:     1043..    1043:      37907..     37907:      1:
   2:     1059..    1059:      37923..     37923:      1:
   3:     9251..    9256:      46115..     46120:      6:
   4:    32768..   32770:      51200..     51202:      3:      69632:
   5:    34816..   55295:      77824..     98303:  20480:      53248:
   6:    55296..   57343:     114688..    116735:   2048:      98304:
   7:    57344..   69631:     120832..    133119:  12288:     116736:
   8:    69632..   81919:     102400..    114687:  12288:     133120:
   9:    81920..   98303:     135168..    151551:  16384:     114688:
  10:    98304..   98306:      57344..     57346:      3:     151552:
  11:   100352..  112639:     151552..    163839:  12288:      59392:
  12:   112640..  145407:     165888..    198655:  32768:     163840:
  13:   145408..  163839:     198656..    217087:  18432:
  14:   163840..  163842:      40960..     40962:      3:     217088:
  15:   165888..  178175:     217088..    229375:  12288:      43008:
  16:   178176..  202751:     231424..    255999:  24576:     229376:
  17:   202752..  206847:     258048..    262143:   4096:     256000:
  18:   206848..  216756:     276480..    286388:   9909:     262144:
  19:   229376..  229378:      43008..     43010:      3:     299008:
  20:   294912..  294914:      53248..     53250:      3:     108544:
  21:   524288..  524288:      55296..     55296:      1:     282624:
  22:   819200..  819202:      61440..     61442:      3:     350208:
  23:   884736..  884738:      63488..     63490:      3:     126976:
  24:  1048576.. 1048577:      67584..     67585:      2:     227328:
  25:  1081344.. 1081391:      69632..     69679:     48:     100352:
  26:  1572864.. 1572864:      71680..     71680:      1:     561152:
  27:  1605632.. 1605634:      73728..     73730:      3:     104448:
  28:  2097152.. 2097152:      75776..     75776:      1:     565248:
  29:  2097167.. 2097167:      75791..     75791:      1:             last
/media/Grafi/sparse-file: 25 extents found

Nie wiem dokładnie jak rozumieć te małe wartości w length, ani dlaczego physical_offset jest w takiej losowej kolejności. Numery tych bloków powinny rosnąć od góry do dołu, a nie raz są mniejsze a raz większe. xD Także, jak ktoś wie jak zinterpretować ten wynik to niech mi napisze.

Plik sparse da radę zdefragmentować i jest brana pod uwagę tylko ta zapisana część tego pliku. Niemniej jednak, ta fragmentacja no jest powalająca, praktycznie nie notuje się pełnych zakresów, tj 32768 bloków (128M). Tam wyżej jest tylko jeden, a plik wgrany miał ponad 600M, więc powinno być ich kilka. Jak ktoś się chce w to bawić, to odradzam. xD

Tego nie wiem ale raczej nikt by nie chciał mieć takiego kontenera 10G z 1k plików w 10k częściach. xD

Ostatnio edytowany przez morfik (2016-06-01 23:07:55)

Mając zwykły plik wypełniony zerami w jednym kawałku i chcąc utworzyć na nim system plików przy mkfs.ext4, to on również zostanie pofragmentowany. Będzie wyglądał tak samo jak ten sparse. Przynajmniej w standardowej konfiguracji, tj. gdy tworzy się system plików bez opcji -E nodiscard . Jeśli się ja zastosuje, to wszystkie zera takiego pliku będą widoczne po stworzeniu systemu plików i taki plik nie będzie ulegał fragmentacji, gdy będziemy wrzucać coś do niego.

Natomiast problem z tymi plikami sparse jest taki, że tutaj już nie ma zer. Dlatego te pliki będą się tak fragmenteować i praktycznie każdy nowy plik wgrany do kontenera sparse doda kolejny nieciągły zakres, czyli pofragmentuje kontener.

W filefrag były widoczne małe zakresy składające się min. z 1-3 bloków. Chodzi o to, że system plików ma swoją strukturę, min. superblock i jego kopie. Te sektory są zapisywane przy tworzeniu systemu plików i plik sparse na samym początku ulega fragmentacji dokładnie w miejscach zapisu tych bloków. Im dłuższy plik, tym więcej jest kopi superbloka i więcej metadanych potrzebnych do opisu zawartości.

# mkfs.ext4 /media/Grafi/sparse-file
...
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

# filefrag -v /media/Grafi/sparse-file
Filesystem type is: ef53
File size of /media/Grafi/sparse-file is 2147483648 (524288 blocks of 4096 bytes)
ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     257:    1507328..   1507585:    258:
   1:      265..     265:    1507593..   1507593:      1:
   2:      272..     273:    1507600..   1507601:      2:
   3:      289..     289:    1507617..   1507617:      1:
   4:     8481..    8486:    1509665..   1509670:      6:    1515809:
   5:    32768..   32769:    1511424..   1511425:      2:    1533952:
   6:    98304..   98305:    1513472..   1513473:      2:    1576960:
   7:   163840..  163841:    1515520..   1515521:      2:    1579008:
   8:   229376..  229377:    1517568..   1517569:      2:    1581056:
   9:   262144..  262144:    1519616..   1519616:      1:    1550336:
  10:  294912..  294913:    1521664..   1521665:      2:    1552384: last
/media/Grafi/sparse-file: 8 extents found

W przypadku zwykłego systemu plików na partycji, to nie stanowi problemu ale, gdy w grę wchodzi jeden system plików opisany w innym systemie plików, to już tego typu mechanizm jest iście niewydolny właśnie przez fragmentację, której moim zdaniem się nie da uniknąć w przypadku plików sparse. xD

Ostatnio edytowany przez morfik (2016-06-02 13:58:47)

Przecież to nie tylko o fragmentację idzie, ta akurat może być pomijalna na urządzeniach nie mechanicznych, ale dodatkowy koszt obsługi urządzeń loop. Tego nie da się pominąć, mimo licznych usprawnień, zawsze będzie istnieć dodatkowy narzut.
https://git.kernel.org/cgit/linux/kernel/git/torval … 588edd15f1778