system plików do archiwizacji

W moim systemie plików mam złożone dane tylko do odczytu. Zawiera tysiące migawek niektórych wersji repozytorium svn oraz wyniki testów regresji. Identyczne pliki między migawkami są już zduplikowane przy użyciu twardych łączy. W ten sposób pojemność pamięci nie musi być duża, ale wciąż zużywa dużo i-węzłów, a to powoduje, że fsck boleśnie długo pracuje dla mojego głównego systemu plików.

Chciałbym przenieść te dane do innego systemu plików, aby nie wpłynęło to zbytnio na główny system plików. Czy masz sugestie? Squashfs wydaje się być możliwym wyborem, ale będę musiał sprawdzić, czy może on skutecznie obsługiwać twarde linki.

Jeśli jest to powolna fsck, czy próbowałeś ext4? Dodali do niego kilka funkcji, które sprawiają, że fsck jest naprawdę szybki , nie patrząc na nieużywane i-węzły :

Fsck jest bardzo powolną operacją, szczególnie pierwszym krokiem: sprawdzenie wszystkich i-węzłów w systemie plików. W Ext4 na końcu tabeli i-węzłów każdej grupy będzie przechowywana lista nieużywanych i-węzłów (z sumą kontrolną, dla bezpieczeństwa), więc fsck nie sprawdzi tych i-węzłów. W rezultacie całkowity czas fsck ulega poprawie od 2 do 20 razy, w zależności od liczby używanych i-węzłów (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). Należy zauważyć, że to fsck, a nie Ext4, zbuduje listę nieużywanych i-węzłów. Oznacza to, że musisz uruchomić fsck, aby zbudować listę nieużywanych i-węzłów, a tylko następne uruchomienie fsck będzie szybsze (musisz przekazać fsck, aby przekonwertować system plików Ext3 na Ext4). Jest też funkcja, która bierze udział w tym przyspieszeniu fsck - „elastyczne grupy bloków”

Btrfs ma natywne wsparcie dla migawek, więc nie będziesz musiał używać twardych linków do deduplikacji. Możesz odtworzyć bieżącą konfigurację, tworząc system plików btrfs i ładując go z najwcześniejszą potrzebną wersją, wykonując migawkę, a następnie przewijając repozytorium do przodu w każdym punkcie, w którym potrzebujesz migawki i wykonując migawkę przy każdym krok. Powinno to być bardziej wydajne niż twarde linki, a także prostsze w konfiguracji.

Myślę też (choć jestem tego pewien), że squashfs transparentnie deduplikuje pliki, więc nawet jeśli nie obsługuje twardych linków, nadal będziesz widzieć korzyści. Jeśli nigdy nie musisz zmieniać danych w systemie plików, prawdopodobnie najlepszym rozwiązaniem jest squashfs, ponieważ fsck można zastąpić md5sum;)

Wolałbym XFS, ponieważ mam bardzo dobre doświadczenia z tym systemem plików. Ale naprawdę polecam, wykonaj test z danymi i wszystkimi sugerowanymi systemami plików.

Znam kilka sklepów, które wykorzystują DataDomain właśnie w tym celu.

Skrypt archiwalny może być bardzo prosty (na przykład tar lub rsync i cron) i nie musisz się martwić o zarządzanie twardymi dowiązaniami lub katalogami, których nie można dowiązać na stałe w większości systemów plików. Nie ma potrzeby tworzenia kopii przyrostowych, z wyjątkiem zachowania przepustowości. Cała magia dzieje się pod warstwą bloku. Nie jest niczym niezwykłym utrzymywanie danych wirtualnych o wartości 15-20 TB przy jednoczesnym wykorzystaniu rzeczywistego miejsca na dysku o wartości 1-2 TB. Nadal pozostanie ci dużo miejsca na kopie zapasowe dysków.

Dane byłyby obsługiwane przez NFS lub iSCSI, ale nie jestem pewien, czy to jest problem

Kiedy FreeBSD otrzyma ZFS v23, deduplikacja będzie dostępna dla reszty z nas.