Które rozmiary bloków dla milionów małych plików

Mam 2x dyski 4 TB w sprzętowym RAID1 (może to być LSI MegaRaid) na Debian Wheezy. Rozmiar bloku fizycznego wynosi 4 kB. Zamierzam przechowywać 150-200 milionów małych plików (od 3 do 10kB). Nie pytam o wydajność, ale o najlepszy system plików i rozmiary bloków, aby zaoszczędzić miejsce. Skopiowałem plik o wielkości 8200 bajtów na ext4 o wielkości bloku 4kB. Zajęło to 32kB dysku !? Czy przyczyną tego jest kronikowanie? Jakie są opcje oszczędzania większości miejsca na tak małe pliki?

— rabudde
źródło

Zobacz także: Jak określić rozmiar bloku partycji ext3 w systemie Linux?

— Chris S

Gdybym był w takiej sytuacji, szukałbym bazy danych, która może przechowywać wszystkie dane w jednym pliku ze zwartym indeksem opartym na przesunięciach, a nie jako osobne pliki. Być może baza danych ze sterownikiem FUSE jest dostępna do interakcji z nią jako plikami, gdy jest to konieczne, bez faktycznego, że WSZYSTKIE osobne pliki.

Alternatywnie możesz spojrzeć na powiedzmy na 60-70 percentyl rozmiarów plików i spróbować dopasować ten rozmiar pliku bezpośrednio do węzłów drzewa systemu plików, a nie jako osobne bloki na dysku. Przechowywanie 10 000 w każdym węźle jest prawdopodobnie dużym pytaniem, ale gdybyś mógł tam znaleźć 60–70% plików, prawdopodobnie byłaby to ogromna wygrana.

Tylko niektóre systemy plików mogą to zrobić (reiserfs to jeden), i myślę, że wszystko zależy od tego, jaki rozmiar ma percentyl, czy będzie on pasował do drzewa. Możesz go dostroić. Chyba staram się dopasować resztę do jednego bloku.

I nie martw się o czasopisma; i tak mają górny limit wielkości.

Nie nie nie nie nie nie nie nie nie tylko ... nie w twoim pierwszym akapicie. Popełniłem ten błąd wiele lat temu i później trzeba go było naprawić. Odziedziczyłem również systemy, które używają tego wzorca projektowego. Pliki należą do systemu plików lub, jako kompromis, do obiektu FileStream programu SQL Server, jeśli należy je połączyć (więc może sterownik FUSE, ale nadal nie). Istnieją inne uwagi podczas pracy w systemie plików, takie jak nie umieszczanie 4 milionów plików w jednym folderze (również popełniłem ten błąd).

— Mark Henderson

@MarkHenderson, ale problemem jest zdefiniowanie, CO POWINIEN być plikiem, a jaki powinien być rekordem. Bez podania dalszych szczegółów setki milionów drobiazgów wydają mi się DUŻO bardziej jak płyty. Tylko dlatego, że obecnie ma je jako pliki, nie oznacza to, że muszą pozostać w ten sposób, a nawet tak powinno być. Poza tym nigdy nie zasugerowałem użycia SQL Servera do zadania;)

5 lat temu odziedziczyłem system z 1 milionem plików w jednym folderze i około 10 000 nowych plików 1-4 KB dziennie. Postanowiłem wrzucić je wszystkie do tabeli ISAM, ponieważ „Hej, to tylko zwykły tekst do analizy!” a potem okazało się to wielkim błędem, ponieważ miałem teraz pojedynczy stół o pojemności 12 GB z rzędami squillionów, które w większości nie robiły nic po ich przetworzeniu. Wróciłem więc do umieszczania ich w systemie plików z folderami dziedzicznymi opartymi na GUID nazwy pliku.

— Mark Henderson

(dlaczego pojedynczy stół o pojemności 12 GB z kwadratowymi rzędami stanowił problem, to inna sprawa, o której tu nie będę wspominał)

— Mark Henderson

@MarkHenderson: To nie jest inny problem, DLACZEGO powiedziałeś, że to niewłaściwe rozwiązanie („... wielki błąd, ponieważ miałem teraz pojedynczy stół 12 GB z rzędami squillionów ...”). Wybrałeś niewłaściwy format silnika / tabeli bazy danych, ale koncepcja umieszczenia wielu małych rzeczy w jednym pliku z INDEKSEM jest słuszna, o ile robisz to dobrze. To, czego chcesz, to baza danych, która wyróżnia się w magazynach kluczy / wartości dla milionów małych obiektów, z funkcją automatycznego dzielenia. Zauważ też, że specjalnie nie troszczy się o wydajność, tylko o przestrzeń.