Jakie systemy plików pozwalają na zmianę położenia początku pliku?

Question

Typowe systemy plików i interfejs POSIX pozwalają na zmianę rozmiaru pliku tylko na końcu. Zazwyczaj rozmiar pliku "na dysku" po jego zamknięciu jest równy przesunięciu pozycji odczytu/zapisu, gdy był zamknięty. Szukanie przed zamknięciem jest również znane jako "repozycjonowanie końca pliku".

Plik zawierający kolejkę danych byłby bardziej efektywnie reprezentowany przez operację usunięcia początku pliku. Bloki alokacji na dysku na początku mogą zostać zwolnione, a niepotrzebne kopiowanie zminimalizowane.

Czy jest to obsługiwane bezpośrednio przez dowolny wspólny system plików i/lub system operacyjny? Jakiego interfejsu używa się do tego? (Na przykład selektor Linux fcntl). Jestem pewien, że słyszałem o takich rzeczach w praktyce.

Answer 1

Właściwie Linux robi mieć interfejs, który robi to, co prosisz. Jest to flaga FALLOC_FL_COLLAPSE_RANGE do fallocate. Jest obsługiwany przez btrfs, ext4 i xfs (prawdopodobnie inne) na nowoczesnych jądrach. Mimo że interfejs Fallocate umożliwia określenie przesunięć i długości bajtów, w praktyce wywołanie COLLAPSE_RANGE będzie działało tylko wtedy, gdy przesunięcie i długość będą wielokrotnością rozmiaru bloku systemu plików.

Aby uzyskać więcej informacji, proszę zobaczyć Fine podręcznik dla fallocate (2) wywołanie systemowe: http://man7.org/linux/man-pages/man2/fallocate.2.html

Answer 2

Najbliższe, jakie widziałem, to formaty plików wskazujące, że dane zostały "usunięte", a następnie usunięte miejsce może zostać ponownie użyte po. Zwykle działa tylko z formatami rekordów o stałej długości, na przykład DBF, i wymaga nieco więcej pamięci, aby zachować zarówno indeksy usuniętych rekordów do ponownego użycia, jak i kolejność rekordów w pliku.

Answer 3

Nie. Nie w świecie Unixów, w każdym razie.

Jeśli zajrzysz do wnętrza systemu plików DBMS lub Unix (ish), mogą one łatwo skracać lub rozszerzać zbiory danych na początku, na końcu lub w dowolnym miejscu w środku. Ale nie eksportują tej funkcji; nie jest częścią dziedzictwa API Uniksa ani standardu POSIX, więc wszelkie API "skracania na początku" lub "rozszerzania na początku" byłyby niestandardowe ("zastrzeżone").

Marginalna użyteczność takich funkcji również jest niejasna. Kto by z nich skorzystał? Jak często?

Pliki uniksowe (płaskie sekwencje bajtów/znaków) sprawdziły się jako proste i skuteczne w kodzie aplikacji, ale stanowią słabą podstawę dla warstwowych struktur danych. Dwadzieścia pięć lat temu to oświadczenie było dyskusyjne; dziś jest to tylko obserwowana rzeczywistość historyczna.

Deweloperzy Unixa twierdzili, że "wszystko można zredukować do plików" i "możemy uzyskać assemiczny dostęp poprzez sprytne poszukiwanie". Twierdzenia te jednak nigdy się nie udało. Unix nigdy, na przykład, nie pasował do zarządzania rekordami dostępu losowego systemów operacyjnych minikomputerów i komputerów mainframe (na przykład DEC RMS, IBM ISAM i VSAM). Podczas gdy te implementujące systemy plików, kolejki, próby, relacyjne bazy danych i magazyny obiektów czasami upuszczają zawartość do plików i używają plików do sekwencyjnych operacji, takich jak rejestrowanie, ale rzadko zależą od strumieni znaków w ich formacie niskiego poziomu. Zamiast tego używają struktur takich jak drzewa B i tabele mieszania, aby bezpośrednio zarządzać blokami dysku, segmentami pamięci i innymi zasobami bazowymi.

Strumienie znaków należą do tabel, dokumentów i obiektów - abstrakcje odpowiednie dla aplikacji klienckich. Jeśli chcesz kolejkę, rozważ wykorzystanie istniejącego oprogramowania pośredniego (np. RabbitMQ, ZeroMQ, REDIS, niektóre menedżer DBMS), które już to obejmuje. Jeśli musisz zbudować to sam, prawdopodobnie nie zbudowałbyś go na uproszczonej abstrakcji strumienia znaków. Więc podczas skracania/rozszerzania na początku jest potencjalnie przydatne dla niektórych rzeczy (przycinanie dziennika zamiast segmentacji rotacji dziennika, np.), Jest mało prawdopodobne, aby być Wielką Wygraną dla większości implementacji struktury danych.

Answer 4

Zmiana położenia początku pliku prawdopodobnie nie jest dobrym pomysłem. Mogłoby to zmylić procesy posiadające deskryptory plików otwarte dla tego pliku i oczekiwać, że będą one poprawnie wyświetlane, tj. Mają przewidywalne przesunięcie.

Jeśli Twoim głównym celem jest zaoszczędzenie miejsca na dysku, istnieje kilka podejść.

Jeśli masz obsługę ZFS i włączasz deduplikację, bloki poprzednio używane do przechowywania danych z początku (lub dowolnej części pliku) mogą zostać zwolnione poprzez nadpisanie ich zerami.

Pod Linuksem powinieneś być w stanie uwolnić części magazynu plików w systemie plików obsługującym pliki rozrzedzone (większość z nich) za pomocą wywołania systemowego fallocate i przekazując mu flagę FALLOC_FL_PUNCH_HOLE. Solaris dostarcza podobną komendę fcntlF_FREESP. To, czy fallocate lub fcntl będzie działać wydajnie czy w ogóle, zależy od implementacji.

Alternatywnie Po uruchomieniu systemu operacyjnego, który nie zapewnia fallocate lub równoważną funkcjonalność ale obsługuje ZFS (np: FreeBSD), i/lub jeśli deduplikacji nie jest opcją, ponieważ nie masz wystarczającej ilości pamięci RAM, aby przeznaczyć na to, lekką alternatywą byłoby po prostu włączyć kompresję w systemie plików.