Trwa konkurs "Ogól naczelnego", w którym codziennie możecie wygrać najnowsze maszynki systemowe Hydro Connect 5 marki Wilkinson Sword.

Więcej informacji
Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Btrfs — elegancki system plików na cywilizowane czasy

Po przeczytaniu tytułu nie trudno domyśleć się o czym będzie traktował ten wpis. Otóż to – w tym wpisie chciałbym przedstawić system plików Btrfs i opisać nieco jego funkcje podając przykłady. Btrfs nie jest dzisiaj zbyt popularnym rozwiązaniem głównie poprzez przekonanie o jego niestabilności. Czy słuszne czy nie – ciężko ocenić. Faktem jest, że większość funkcji tego systemu plików jest już stabilna i można w miarę bez obaw używać ich do pewnych czynności. O stabilności tego systemu plików traktuje FAQ na jego oficjalnym wiki, polecam przeczytać ten punkt, a najlepiej całe FAQ, jeżeli masz chęć go użyć. Można je znaleźć tutaj.

Btrfs został zapoczątkowany w 2007 roku. Został głównie zaprojektowany przez firmę Oracle specjalnie dla Linuksa. Bazuje on na zasadzie CoW (Copy on Write). CoW to technika dla kopiowania lub duplikowania danych polegająca na tym, że dane nie są fizycznie kopiowane dopóki oryginał nie zostanie zmodyfikowany. Zwiększa to wydajność i zmniejsza użycie zasobów poprzez ograniczenie używania niepotrzebnych operacji kopiowania. W momencie żądania skopiowania danych zwracany jest wskaźnik na „skopiowane” dane, które fizycznie są kopiowane dopiero wtedy, jak oryginał zostaje zmodyfikowany. Ta technika jest szeroko wykorzystywana nie tylko w systemach plików, ale także w zarządzaniu pamięcią i innych. Btrfs używa B-drzewa (stąd też podaje się rozwinięcie nazwy systemu plików jako „B-tree File System") jako struktury przechowywania danych. Sam system plików powstał jako odpowiedź na braki w systemach plików Linuksowych, które nie zapewniały same z siebie takich funkcji jak np. snapshoty czy sumy kontrolne.

Warto dodać, że te funkcje zapewnia ZFS (system plików pierwotnie dla Solarisa, dzięki otwarciu kodu znalazł potem też miejsce w innych systemach jak np. FreeBSD), który powstał przed Btrfs. Niestety licencja ZFS (CDDL) uniemożliwia bezpośrednie włączenie jego kodu bezpośrednio do jądra Linux. Btrfs powstaje jako alternatywa dla niego będąca bezpośrednią częścią jądra. ZFS dzisiaj cieszy się jednak znacznie większą popularnością, głównie ze względu na dopracowanie i przetestowanie. Chociaż i Linuksowy twór też znajduje swoje zastosowanie w biznesie – Facebook używa go na części swoich serwerów. Sam Theodore Ts’o (deweloper systemów plików ext) określa go jako przyszłość Linuksa.

Najważniejsze możliwości

Btrfs jest prawdopodobnie najbardziej zaawansowanym systemem plików dostępnym bezpośrednio w jądrze Linux. Stąd też zapewnia całkiem sporo możliwości a i w planie są kolejne. Sprawdźmy więc co on potrafi.

Sumy kontrolne

Btrfs wylicza sumy kontrolne dla każdego pliku by zapewnić jego poprawność. Używa do tego funkcji crc32c. Zwiększa to pewność poprawności danych.

Przezroczysta kompresja

Jedna z największych funkcji tego systemu plików. Przezroczysta kompresja pozwala na kompresowanie plików na poziomie systemu plików (programy z nich korzystające nie „zauważą” żadnej różnicy) dzięki czemu pozwala oszczędzić miejsce na dysku, a także, w pewnych przypadkach, zwiększyć szybkość odczytu. Aktualnie są dostępne dwa algorytmy kompresji – zlib (domyślny w przypadku braku sprecyzowania opcji) i lzo, planowany jest także lz4 znany z ZFS. Zlib ma wyższy stopień kompresji jest jednak wolniejszy, lzo jest szybszy, lecz kosztem gorszego stopnia kompresji. Montując system plików możemy sprecyzować 2 opcje – są to compress lub compress-force (w każdej opcji możemy sprecyzować algorytm kompresji poprzez wpisanie jego nazwy po znaku '=' np. compress=lzo). Druga opcja różni się od pierwszej tym, że wymusi kompresję na plikach, które nie kompresują się dobrze, lub zostały oznaczone by nie używać kompresji. Możliwe jest wyłączenie kompresji dla wybranego katalogu/pliku poleceniem:btrfs property set <plik> compression ""Wybrany plik nie będzie kompresowany do czasu wyczyszczenia flagi poprzez użycie powyższego polecenia precyzując algorytm, lub poleceniem: chatrr +c Warto dodać, że jeżeli system plików został zamontowany z opcją wymuszającą kompresję nie będzie brał pod uwagę tej flagi. Kolejną sprawą jest to, że włączając/wyłączając kompresje dla danego pliku jego stan nie zostanie zmieniony – będzie to dotyczyło tylko nowych danych. Można jednak wymusić kompresję poprzez defragmentacje poleceniem btrfs filesystem defragment -c <system_plikow>

Subwoluminy (ang. subvolumes)

Kolejna duża funkcja Btrfs. Na tyle, że zaprezentuje ją praktycznie. Subwoluminy to niezależnie montowane drzewo plików POSIX i nie może być traktowane jako urządzenie blokowe (bo nim nie jest). Większość systemów plików Uniksowych posiada jeden katalog główny (określany jako /), który jest najwyższym możliwym katalogiem. Btrfs również takowy posiada, jednak może mieć ich więcej właśnie dzięki subwoluminom. W ramach subwoluminów można tworzyć kolejne, a także przechowywać tam dane. Najwyższy subwolumin Btrfs (zawsze o ID 5) jest tworzony automatycznie przy formatowaniu partycji i nie może być usunięty. W jego ramach możemy tworzyć także inne, za pomocą polecenia: btrfs subvolume create /katalog/nazwaW systemie są one widoczne jako zwykłe katalogi, jednak mają swoją cechę unikalną – mogą być zamontowane tak, by były głównym katalogiem systemu plików. Umożliwia to opcja montowania subvol=nazwa. Możliwa jest też miana domyślnego subwoluminu z głównego na inny poleceniem: btrfs subvolume set-default subvolume-id /Wracając jednak do opcji subvol – po jej użyciu dany subwolumin zostanie użyty jako główny katalog systemu plików i tak właśnie będzie widoczny w zamontowanym katalogu.

Żeby to lepiej zaobrazować przedstawię to praktycznie używając mojego Antergosa, na którym pracuję na co dzień i który używa Btrfs na partycji /. Dla ułatwienia posłużę się jednak plikiem. Tworzę więc plik o wielkości około 300MB programem dd, następnie formatuję go na Btrfs poleceniem: mkfs.btrfs plik.imgmontuję w katalogu /mnt. Narazie bez żadnych opcji.

Jak widać nic tutaj nie ma. Dlatego stwórzmy sobie jakieś subwoluminy. Nazwę je SUBVOL1 i SUBVOL2.

Subwoluminy zostały stworzone. Jak widać, są widoczne jako zwykłe katalogi. Teraz odmontujemy obraz partycji i zamontujemy go precyzując subwolumin za pomocą polecenia (zamiast opcji subvol można też użyć opcji subvolid i podać ID odczytane podanym wyżej poleceniem) :mount -t btrfs -o subvol=SUBVOL1 /plik.img /mnt

Jak widać teraz SUBVOL1 jest głównym katalogiem i obecnie nie możemy przeczytać zawartości SUBVOL2 za pomocą ls, gdyż nie mamy do niego już dostępu. Na zamontowanym subwoluminie możemy robić wszystko to, co na normalnej partycji z tą różnicą, że wszelkie dane są zapisywane właśnie w sprecyzowanym subwoluminie, a reszta jest nieruszana. Odmontujmy teraz obraz, zamontujmy go ponownie bez precyzowania opcji.

Myślę, że to wystarczający przykład działania subwoluminów. Można ich także użyć do symulowania partycji – stworzyć ich wymaganą ilość i zamontować do różnych katalogów (np. do / i do /home). Z punktu widzenia programów będą to niezależne partycje, z punktu widzenia systemu plików wszystko będzie się odbywało na jednej partycji.

Niestety subwoluminy mają też jedną wadę – nie da się ich montować z różnymi opcjami. Przy montowaniu kilku subwoluminów tylko opcje montowania pierwszego zostaną odczytane. To braki w implementacji i jest możliwość, że w przyszłości zostanie to poprawione (chociaż wierząc wiki nie będzie to proste zadanie ze względu na specyfikę VFS Linuksa).

Migawki

Kolejna ciekawa opcja bardzo mocno powiązana z poprzednią. Btrfs pozwala tworzyć migawki dla wybranego subwoluminu. Migawka jest tworzona niemal natychmiast dzięki technice CoW. Ta sama technika sprawia też, że migawka początkowo nie zajmuje dużo miejsca – zacznie rosnąć w miarę zmian w skopiowanym subwoluminie. Sama migawka z poziomu systemu plików niczym nie różni się od subwoluminu – odróżnia ją tylko to, że została stworzona jako kopia subwoluminu, nie od zera. Za pomocą migawki możemy przywrócić subwolumin do stanu, w którym był w momencie jej tworzenia. Jest to przydatna opcja, którą można wykorzystać w razie np. awarii po aktualizacji czy skasowania niechcący ważnego pliku. Należy jednak pamiętać o odpowiedniej wielkości partycji – migawka w najgorszym razie może przyjąć rozmiar subwoluminu w momencie jego klonowania. Dzięki technice CoW można być jednak pewnym, że nie będą niepotrzebnie dublowane dane.

Sprawdzimy sobie tę opcję w praktyce. Jak pewnie pamiętacie z poprzedniego punktu – na SUBVOL1 znajduje się plik tekstowy o nazwie plik1 z zawartością „test”. Do testu stworzę jeszcze jeden plik o nazwie plik2. Zrobimy sobie teraz migawkę SUBVOL1 o nazwie SUBVOL1-SNAPSHOT i zmodyfikujemy zawartość pliku plik1 oraz skasujemy plik2, a następnie podejrzymy jak się przedstawia zawartość migawki. Migawki tworzymy poleceniem: btrfs subvolume snapshot nazwa nazwamigawki

Myślę, że nic więcej wyjaśniać nie trzeba. Teraz w razie konieczności możemy cofnąć subwolumin do jego migawki. Aby to zrobić wystarczy go skasować poleceniem:btrfs subvolume delete nazwa i po prostu użyć polecenia mv zmieniając nazwę migawki na nazwę subwoluminu.

To wszystko. Zauważyć należy jednak, że ID subwoluminu uległo zmianie na takie, jakie miała migawka. Dlatego bezpieczniej odwoływać się po nazwie. No chyba, że po przywróceniu migawki zadbacie o poprawę ID w bootloaderze czy /etc/fstab.

Deduplikacja

Jedna z najważniejszych funkcji Btrfs, która bywa też podawana jako główna zaleta jego konkurenta, czyli ZFS. Deduplikacja pozwala zredukować ilość zajmowanego miejsca poprzez złączenie powtarzających się danych w jedno. Jej zastosowania mogą być różne, w Linuksie często mówi się o połączeniu deduplikacji z kontenerowaniem aplikacji. Snap, Flatpak czy AppImage rozwiązują problem z mnogością dystrybucji poprzez dystrybuowanie aplikacji wraz ze wszystkimi potrzebnymi jej zależnościami. Jednak w przeciwieństwie do tradycyjnych zależności współdzielonych zajmuje to więcej miejsca na dysku – każda aplikacja ma swoje zależności i nie baczy na inne. To powoduje, że możemy mieć na dysku wiele kopii tej samej biblioteki. Deduplikacja jest rozwiązaniem tego problemu – powinna wyłapać powtarzające się dane i złączyć je w jedno.

Niestety Btrfs, w przeciwieństwie do ZFS, nie obsługuje jeszcze deduplikacji w trakcie. Oznacza to, że Btrfs nie jest w stanie dokonać deduplikacji w czasie zapisywania danych. Można ją wykonać dopiero po zapisaniu danych za pomocą dedykowanych narzędzi takich jak dedupremove, bedup albo btrfs-dedupe. Taki rodzaj deduplikacji jest nazywany „offline”, chociaż to nazwa dość myląca (bo jest wykonywana na zamontowanej i pracującej partycji), więc lepiej używać nazwy „out of band deduplication” lub „batch deduplication”.

Pracę nad deduplikacją w trakcie zapisu danych trwają i są już gotowe łatki, które jednak są określone jako eksperymentalne i przez to nie są jeszcze załączone do głównego kodu Btrfs. W przyszłości można się spodziewać włączenia ich do głównego kodu.

Wbudowana obsługa wielu urządzeń

Podobnie jak ZFS, Btrfs ma też wbudowaną obsługę wielu urządzeń, czyli RAID. RAID w największym skrócie to sposób wykorzystania dwóch lub więcej dysków twardych, które ze sobą współpracują. Jak ktoś chce wiedzieć więcej, to polecam przeczytać o tym tutaj. Tworzenie macierzy RAID w Btrfs jest dość proste – trzeba po prostu sprecyzować więcej urządzeń w poleceniu mkfs.btrfs. Żeby to pokazać użyję maszyny wirtualnej (z 3 wirtualnymi dyskami o wielkości 1GB każdy), na której wystartuję Arch Linuksa z obrazu płyty.

Stworzenie macierzy w Btrfs nie jest specjalnie skomplikowane. Wystarczy uruchomić mkfs z opcją -d raid0 i podać urządzenia, na których ma być macierz utworzona. W maszynie wirtualnej są to /dev/sda, /dev/sdb i /dev/sdc. Tak więc komenda wygląda tak: mkfs.btrfs -d raid0 /dev/sda /dev/sdb /dev/sdc

W celu zamontowania tak stworzonej macierzy wystarczy wywołać komendę mount i podać dowolne urządzenie wchodzące w skład macierzy. Tak więc montujemy i sprawdzamy.

Jak widać macierz została zamontowana poprawnie i polecenia pokazują, że urządzenia zostały połączone w RAID0. Komendzie df nie ma co ufać w przypadku Btrfs (zdarza jej się pokazywać błędnie ze względu na jego specyfikę) jednak w tym przypadku pokazuje rozmiar przestrzeni na 3GB, co jest łączną przestrzenią 3 wirtualnych dysków po 1GB każdy.

Wydaje mi się, iż opisałem najważniejsze funkcje Btrfs, które wyróżniają go na tle innych systemów plików. Oczywiście to nie wszystko i zawiera ich znacznie więcej. O jego wszystkich funkcjach czy cechach można przeczytać tutaj.

Wady

Niestety Btrfs pomimo swojego zaawansowania ma też i wady. Oto część z nich (porównanie do ZFS celowe, w końcu Btrfs ma być jego odpowiednikiem):
-Brak deduplikacji inline – wspominałem o tym w poprzednim punkcie. Btrfs jeszcze nie umożliwia deduplikacji w trakcie działania. Jedyna opcja to jej wykonanie po zapisaniu danych. Oczywiście ZFS nie ma z tym problemu.

-Brak wbudowanego szyfrowania – Btrfs nie posiada wbudowanego szyfrowania, podobnego jak ZFS. Nie jest w stanie szyfrować danych na poziomie systemu plików (tak jak kompresować). Można wprawdzie wykorzystać dm-crypt/LUKS lub ecryptfs i szyfrować dane poza systemem plików, ale wbudowana funkcja znacząco by to ułatwiła. Póki co nikt nie pracuje nad tą funkcją, lecz jest możliwość pojawienia się jej w przyszłości.

-Brak algorytmu LZ4 w kompresji – LZ4 jest wydajnym algorytmem kompresji, który jest używany przez ZFS. LZ4 jest szybszy niż LZO (jedna z opcji Btrfs) oferując podobny stopień kompresji. Niestety deweloperzy Btrfs póki co nie widzą sensu jego implementacji, argumentując to tym, że jego implementacja wymagałaby dodatkowej pracy w celu jego obsługi.

-Gorsza wydajność – Dotyczy to też ZFS. Btrfs jest wolniejszy niż mniej rozbudowane systemy plików (jak np. ext4 czy xfs), co jest szczególnie zauważalne przy pracy na wielu plikach na powolnym dysku (nie polecam używać Btrfs jako / na laptopowym HDD – instalacja czy aktualizacja wielu pakietów naraz trwała u mnie wieki). Ta wada wynika z jego projektu – nacisk jest kładzony na funkcjonalność, nie na szybkość. Stąd też Btrfs nie nadaje się do zadań, gdzie liczy się jak najwyższa wydajność. Nadaje się natomiast do zadań, gdzie narzut na wydajność nie jest szczególnie istotny. Do codziennego używania polecałbym jednak mieć dobry dysk, który zredukuje narzut do akceptowalnego poziomu – chociaż na moim niedrogim SSD jego szybkość też jest akceptowalna.

-Nie pełna stabilność – Nie wszystkie funkcje Btrfs są w pełni stabilne, a niektóre są oznaczone jako niestabilne. Wymaga to rozwagi przy używaniu jego funkcji. Status poszczególnych funkcji można znaleźć tutaj.

-Niedostateczne przetestowanie – Nie jest to wada wynikająca z samego systemu plików, ale go dotyczy. ZFS jest stosowany w wielu zastosowaniach i nie sprawia w nich problemów – cieszy się sporym zaufaniem. Btrfs nie jest tak powszechnie stosowany, dlatego też wielu ludzi jest w stosunku do niego nieufna. Chociaż biorąc pod uwagę powyższy punkt może to i lepiej – lepiej poczekać aż wszystkie jego aspekty zostaną odpowiednio dopracowane niż zrażać do niego ludzi niedopracowanymi funkcjami. Chociaż z drugiej strony brak powszechności oznacza małą ilość zgłaszanych błędów – deweloperzy czy testerzy nie są w stanie przetestować wszystkich wariantów praktycznego używania.

Zakończenie

Na tym ten wpis się kończy. Wydaje mi się, że przedstawiłem najważniejsze funkcje oraz wady tego jakże ciekawego systemu plików. Czy warto go stosować? Jeżeli jakaś jego funkcja Ci się przyda i jest stabilna to tak. Jeżeli nie, to nie. Sam robię użytek z kompresji, która pozwala mi zaoszczędzić miejsce na niewielkim SSD i migawek, które pozwalają mi łatwo przywrócić system w razie awarii (póki co nie musiałem z nich korzystać, oby tak pozostało). Czy ZFS nie byłby lepszym rozwiązaniem? Pewnie by był, ale Btrfs jest dostępny od razu w jądrze i nie ma potrzeby instalować dodatkowych modułów. Póki co nie zaobserwowałem żadnych problemów, pomimo tego, że kilka razy wystąpiło siłowe wyłączenie komputera w trakcie jego pracy. Dziękuję za przeczytanie wpisu i zapraszam do komentowania.

Źródła

btrfs.wiki.kernel.org

wikipedia.org

linux.com 

linux

Komentarze

0 nowych
wielkipiec   16 #1 16.06.2017 00:59

Alec Guinness <3

TestamenT   12 #2 16.06.2017 01:25

Wszędzie gdzie mogę używam XFS,, za stabilność i wydajność. Ale Btrfs kiedyś mnie zainteresował z powodu kompresowania plików. Byłem ciekaw jak to działa bo przypominało mi nieco funkcje kompresowania plików w Windowsie XP. Długo z tego nie korzystałem bo zużycie procesora jakie generowała kompresja była mi nie na rękę. Myślę że Btrfs mógłby dobrze nadawać się na nośniki które służą archiwizacji. I może do tego będę używał Btrfs. Choć w przypadku SSD to może użyłbym f2fs który jest stworzony do tego typu nośników.

Autor edytował komentarz w dniu: 16.06.2017 01:44
  #3 16.06.2017 03:23

Jak ktoś ceni sobie bezpieczeństwo danych to omija ten wybryk natury szerokim łukiem. BTRFS nie jest i długo nie będzie nadawał się do produkcyjnego użycia (IMO nie wydaje mi się by kiedykolwiek dojrzał do produkcji). Używać ZFS i nie marudzić, a puryści od GPL jak mają fantazję to proszę bardzo, nie każdego bawi zaglądanie na półkę z backupami co drugi dzień.

Meszuge   16 #4 16.06.2017 07:18

Nie mogłeś od razu, w pierwszym akapicie, napisać, że to na linucha?

realkrzysiek   9 #5 16.06.2017 07:30

Używam i nie mam z nim problemów, po prostu działa.

Ps. Irytują mnie partycje EFI i zawarty na nich system plików, traktuję to trochę, jak powrót do lat 90".

Autor edytował komentarz w dniu: 16.06.2017 07:33
Cefalon   3 #6 16.06.2017 08:35

Serwery Synology polecają ten system plików przy tworzeniu wolumenów. Także nie jest on taki niepopularny. Podejrzewam, że większość wolumenów na tych serwerach go używa. Na serwerach przeze mnie zarządzanych też na paru stoi i działa.

szydl0   8 #7 16.06.2017 08:37

"-Gorsza wydajność – Dotyczy to też ZFS. Btrfs jest wolniejszy niż mniej rozbudowane systemy plików (jak np. ext4 czy xfs)"

Wypowiem się w temacie ZFS. To zdanie jest prawdą, jeżeli patrzymy z punktu widzenia jednego dysku, na komputrerze z małą ilością RAM. Tylko, że ten system nigdy nie miał na celu działać wydajnie w takim rozwiązaniu.

Jeżeli zaś mamy komputer, który ma np. macierz 12xHDD w mirrorowych parach, szybki Xeon i dużą ilość RAM(32GB+), to odpowiedź jest odwrotna. ZFS skutecznie wykorzystuje dostępne zasoby. Cache'uje w RAMie najczęściej oraz ostatnio wykorzystywane pliki. Przy naprawde dużym zużyciu można dodać szybkie SSD jako Cache drugiego poziomu.

Zasadniczo w takim przypadku wąskim gardłem jest procesor - czy jest w stanie potwierdzić na czas wszystkie wymagane sumy. W każdym razie, ZFS w takim przypadku będzie działać lepiej od prymitywnych systemów, bo po prostu bedzie mógł w stanie wykorzystać zasoby dobrego sprzętu.

elita   6 #8 16.06.2017 09:06

Chyba coś nie tak z tym zapisem crc32 pliku. Zabiłbyś wydajnością fs. Powiedzmy baza danych 10GB w tym 5GB tabela i 5GB 10 plików indeksu. Robisz prosty commit jednego integera, co powoduje seek, write kilku bajtów, sync, close - co robi close na takim fs? Ano czyta 5GB i liczy sumę 5GB to nawet z SSD są sekundy, nie mili.
Wg mnie to crc32 ale bloku logicznego fs, a nie pliku.

elita   6 #9 16.06.2017 09:08

@szydl0: zgoda, gdy cały serwer pełni funkcję NAS i zasoby cpu są potrzebne do obsługi fs bo to kluczowe zadanie w tym przypadku tego sprzętu. Jak serwer pełni inne funkcje (desktop serwer, baza, webserwer, poczta itd) to zasoby cpu są bardziej potrzebne na zadania, a nie celem obsługi fs-a.

silvver   10 #10 16.06.2017 09:26

"Możliwa jest też miana domyślnego subwoluminu z głównego na inny poleceniem:"

literówka "miana"

e X t 7 3   10 #11 16.06.2017 09:35

@Meszuge: Przecież to chyba oczywiste ;)

  #12 16.06.2017 09:40

@Meszuge: A na co niby? Windows obsługuje tylko dwa systemy plików.

szydl0   8 #13 16.06.2017 09:40

@elita: Dobrym działaniem w ogóle jest rozdzielanie kluczowych funkcji na niezależne sprzęty. Wszystko zależy też od skali zadań

Jeśli mamy dwa wymagające zadania, np. hostowanie strony z dużą liczbą zapytań i jeszcze większą bazą Oracle'a oraz NAS dla np. 100 osób wymieniajacych stale wiele GB danych, to naturalnie lepsze będą dwie maszyny, by nie blokowały się wzajemnie.

Natomiast, jeśli mówimy o sytuacji, gdzie duża wydajność jest potrzebna "na życzenie", czyli zazwyczaj obciążenie nie jest intensywne, ale są krótkie momenty, gdy potrzeba dużej wydajności oraz gdy funkcje nie są "kluczowe", to nie widzę powodu by wydajny serwer z ZFS nie podołał zadaniu. CPU jest intensywnie wykorzystywany tylko gdy serwuje pliki, przez większość czasu jest nieużywany. Spokojnie taki Xeon poradzi sobie jednocześnie z prowadzeniem chmury plików, hostowaniem małej strony, obsługą kilkunastu maili czy nawet wirtualizacją(byle wiele ramu nie jadła).

Autor edytował komentarz w dniu: 16.06.2017 09:43
hiropter   11 #14 16.06.2017 09:45

@szydl0: Btrfs dobry, ale nie na desktop. Potrafi całkiem długo myśleć nad usunięciem pojedynczego pliku - archiwum o wielości około 290 GB zajmuje jakieś 25 do 30 sekund.

hiropter   11 #15 16.06.2017 10:15

@szydl0: Mnie zawsze uczyli, że jeden serwer, to jedna usługa. Pliki na jednym wypasionym serwerze, reszta przyłączona przez iSCSI.

SystemError   4 #16 16.06.2017 10:18

@szydl0: Czy możesz podzielić się tutaj wynikami pomiaru szybkości działania takiej macierzy 12XHDD pod ext4 i pod btrfs? Zarówno zapis, jak i odczyt.

Formbi   6 #17 16.06.2017 10:26

Linux to jądro, a nie system operacyjny

szydl0   8 #18 16.06.2017 10:30

@hiropter Bardzo dobrze Cię uczyli :). iSCSI niestety ciężko współpracuje z systemami Copy-on-write, trzeba się trochę pomęczyć z optymalizacją konfiguracji, a potem badać czy nie przekraczamy odpowiedniego progu danych bo wydajność poleci na łeb.

@SystemError Tutaj znajdziesz dobre zestawienie, ale ZFS: https://calomel.org/zfs_raid_speed_capacity.html

Bierz pod uwagę, że to analiza samych konfiguracji dyskowych, więc włączenie kompresji i Cache w RAMie dodatkowo zwiększy transfery.

  #19 16.06.2017 10:31

@szydl0: Nie zgodzę się z Tobą. Używałem ZFS w warunkach produkcyjnych (na Proxmoxie). Serwer DELL z 12 rdzeniami, 128 GB RAM, RAID 5 z 13 dysków. Po przesiadce z ZFS na ext4 czas tworzenia kopii zapasowych maszyn wirtualnych uległ sporemu skróceniu. I to nie kwestia minut tylko godzin. Fakt że kopie zajmowały prawie 1TB.

hiropter   11 #20 16.06.2017 10:43

@szydl0: Optymalizacja zawsze jest ciekawa... pamiętam jak przez parę tygodni walczyłem z Novellem, który dusił się i krztusił na sprzęcie na którym powinien latać - podstawowa konfiguracja potrafiła zbić transfer do 56Kbps/s, po optymalizacji spokojnie korzystał z dobrodziejstwa sieci 100Mb/s (jak na szkolne warunki).

parranoya   9 #21 16.06.2017 11:00

"-Gorsza wydajność"
Na moim domowym serwerze plików (Samba + LVM + dm-crypt) btrfs nie dość, że ma najwyższą wydajność w porównaniu do ext4 i xfs to jeszcze jako jedyny nie przeszkadza w usypianiu dysków.
Co do stabilności to też bym polemizował. Pomimo tego, że działa na archaicznej wersji (Debian Stable 7 i upgrade do 8) już kilka lat, nigdy nie miałem z nim problemów. Wszystko działa jak należy: pliki nie giną, dysk SSD działa bezawaryjnie, wydajność OK.

Druedain   14 #22 16.06.2017 11:10

@dragon321 Coś tam się dzieje w temacie kompresji https://marc.info/?l=linux-btrfs&m=149711863128685&w=2 .

szydl0   8 #23 16.06.2017 11:11

@Anonim (niezalogowany): Maszyny wirtualne, podobnie jak iSCSI to jest właśnie taki typ danych, na który trzeba bardzo uważać przy systemach Copy-on-Write. W twojej sieci najprawdopodobniej doszło do dużej fragmentaryzacji danych tych maszyn.

ZFS pod takie dane trzeba pierw odpowiednio przygotować, skonfigurować, a potem wykonywać regularny maintenance, inaczej zarżniemy go.

  #24 16.06.2017 11:19

system przede wszystkim nie ma trudnej historii jak reiser4

Berion   15 #25 16.06.2017 11:22

Ostatnio głosując na wpisy miesiąca miałem dylemat czy na pewno wykorzystać trzy głosy czy jednak mniej (taka jakość...). W tym miesiącu masz już jeden mój zarezerwowany. :)

qbpm   4 #26 16.06.2017 12:28

Wszystko super, tylko kiedyś napisali, że raid5 jest stabilny, i zbudowałem sobie taką macierz 3xHDD w raid5. Po uszkodzeniu 1 hdd co prawda dane udało się odzyskać, ale macierzy nie udało się odbudować. Dobrze, że zacząłem odbudowywać dopiero po skopiowaniu danych, ponieważ przy próbie odbudowy dostawałem błąd Segmentation Fault. Po drugiej próbie i ponownym Segmentation Fault dane przestały być czytelne i pozostało tylko to zaorać... Teraz mam 2 osobne macierze raid0, na których jedna jest kopią drugiej. A miało być tak pięknie....

~MacG   5 #27 16.06.2017 12:45

@Meszuge: Ty poważnie?

Juche   5 #28 16.06.2017 12:49

Mogę się mylić, ale jakoś tak średnio widzę sens korzystania z Btrfs w domowym zaciszu. Z opisu wnioskuję, że to raczej system na wydajne maszyny z dużą ilością dysków (serwery?) - czy z desktopowego (nieprofesjonalnego) punktu widzenia ma on jakaś istotną przewagę nad choćby ext4?
Przy okazji stawiania jakiegoś NAS pewnie bym rozważył Btrfs, ale póki co jakoś mnie nie przekonuje do przesiadki na pececie.

  #29 16.06.2017 13:17

Ja czytałem, że btrfs nie jest polecany na ssd bo szybko je zajeżdża ze względu na dużą ilość operacji zapisu. A po za tym trimowania nie obsługiwał (nie wiem jak teraz).

Meszuge   16 #30 16.06.2017 13:18

@~MacG: Nie. A co?

tomangelo   6 #31 16.06.2017 13:20

@Juche: jak masz SSD bez HDD i każdy gigabajt oglądasz z dwóch stron to pewnie dzięki deduplikacji trochę pojemności zaoszczędzisz. W sumie chyba tyle.

dragon321   11 #32 16.06.2017 13:30

@wielkipiec: Oryginalna trylogia <3

@TestamenT: Przy zapisie dużych danych pewno i zużywa procesor. Ja nie zauważyłem większego zużycia procesora, ale z drugiej strony nie monitoruję go na bieżąco i nie porównywałem tego. Masz rację, Btrfs nadaje się m.in. tam, gdzie przechowuje się dużo danych a wydajność nie musi być jak najlepsza. Podobnie jak ZFS - ten sam target.

@Meszuge: A u Microsoftu dzieje się coś ciekawego i godnego uwagi w temacie systemów plików? Z tego co wiem to ReFS funkcjonalnie jest gorszy niż NTFS, więc nie wiem czy warto o nim pisać.

A Maca nie posiadam, więc o nowym systemie plików Apple nie napisze :)

@realkrzysiek: Też go używam na partycji /. Również nie sprawia mi problemów pomimo tego, że parę razy zdarzyło się siłowo wyłączyć komputer. Nadal stoi i nie wykazuje problemów. A kompresja i migawki ułatwiają żywot.

No cóż, za to należy podziękować Microsoftowi. Nie przeszkadza mi to szczególnie, bo partycji EFI i tak się nie używa do niczego więcej niż przechowywania bootloaderów.

@Cefalon: Ależ jest stosowany. Jednakże ZFS cieszy się większą popularnością. Dlatego, że poprostu jest dojrzalszy. A Btrfs też będzie - w końcu jest częścią Linuksa, który, w przeciwieństwie do desktopu, trzyma w garści sporo serwerów.

@szydl0: Ze względu na swoją specyfikę i tak będzie wolniejszy niż prostszy system plików. Z bardzo prostego powodu - ZFS robi znacznie więcej niż tylko zarządza plikami na dysku. A prosty system plików nie ma aż tyle roboty. No chyba, że ma się na tyle potężny procesor i dużo RAM, że zredukuje ten narzut - no to wtedy tak, różnicy może nie być.

@elita: Wiki mówi o tym, że suma kontrolna jest wyliczana dla danych i metadanych (data and metadata). Prawdopodobnie jest jak mówisz - nie znalazłem dokładnego tego potwierdzenia.

@silvver: Dzięki, poprawię.

@parranoya: W pewnych przypadkach może być szybszy. Ale w wielu niestety jest wolniejszy. Boleśnie się o tym przekonałem jak bez większego namysłu wsadziłem btrfs dla / na laptopowym HDD. Choćby instalacja wielu pakietów naraz trwała wieki. Dopiero na SSD (z identycznymi opcjami) nie odczuwa się już zbytnio narzutu. Nie jest może tak szybki jak ext4, ale jego prędkość jest w pełni akceptowalna.

@Berion: Dzięki :)

@qbpm: Trochę mało informacji podałeś. Kiedyś czyli kiedy? No i co konkretnie było napisane? Btrfs ciągle leci naprzód. Jak chce się go używać na poważnie, to najlepiej zaopatrzeć się w nowe jądro.

@Juche: Ja znalazłem sens (taki jak wspomniałem we wpisie) - kompresja oszczędzająca miejsce na niewielkim SSD i migawki pozwalające mi łatwo postawić system na nogi w razie awarii lub mojego błędu (przezorny zawsze bezpieczny). W przypadku upowszechnienia się kontenerów deduplikacja też się przyda, by zredukować ilość zajmowanego miejsca.

Autor edytował komentarz w dniu: 16.06.2017 13:30
dragon321   11 #33 16.06.2017 13:30

@Druedain: Dobrze wiedzieć, dzięki za link.

Z tego co widzę, to link podany przez Ciebie traktuje o wbudowaniu kompresji do Btrfs. Niestety narazie póki co autor patchy nie wysłał ich do deweloperów systemu plików (tak napisał we wiadomości). Mam nadzieję, że jak to zrobi, to zostaną przyjęte. Już wcześniej ktoś też napisał podobne łatki, no ale przyjęte nie zostały (nie pamiętam z jakiego powodu).

Autor edytował komentarz w dniu: 16.06.2017 13:35
Apokryf   2 #34 16.06.2017 13:31

@Juche: używam btrfs na laptopie. W domowym zastosowaniu ma wiele zalet, np. formatując w całości dysk w systemie btrfs nie jestem ograniczony wielkością partycji. Każdy wolumen ma dostęp do całej dostępnej pamięci na dysku. Tym samym mogę mieć zainstalowanych kilka różnych dystrybucji na osobnych wolumenach, a zajmują tylko tyle miejsca ile pliki danego systemu. Inne zalety były wspomniane w artykule, np. snapshoty i deduplikacja.

Autor edytował komentarz w dniu: 16.06.2017 16:05
szydl0   8 #35 16.06.2017 13:53

dragon321: ZFS robi więcej, ale też lepiej wykorzystuje sprzęt poprzez:

- ARC, L2ARC i ZIL (cache w Ramie i SSD)
- przeźroczystą kompresje - przyśpiesza transfer i zmniejsza objętość danych
- Bezpośrednie zarządzanie Raidem

Żeby nie pozostać gołosłownym:

https://www.duo.uio.no/bitstream/handle/10852/42152/thesis.pdf?sequence=7

Porównaj strony 57 i 61, ZFS RaidZ1 vs ext4 Raid5.

To z czym sie ściga ZFS to goła prędkość odczytu z dysku przy prostych FS. Tak, musi dodatkowo zwolnić przez przeliczanie sum kontrolnych, ale nadrabia w innych miejscach. A przy wystarczająco szybkim CPU sumy kontrolne nie będą problemem.

Autor edytował komentarz w dniu: 16.06.2017 13:57
qbpm   4 #36 16.06.2017 13:56

@dragon321: Nie widzę tutaj niczego strasznego: https://web.archive.org/web/20160123021613/https://btrfs.wiki.kernel.org/index.p... i ta informacja wisiała przez kilka miesięcy.
natomiast obecnie strona wygląda tak:
https://btrfs.wiki.kernel.org/index.php/RAID56
1 dysk przerywał i nie była to wina kabelków. W końcu fs sie przestał montować ale dało się go zamontować bez tego dysku w degraded, więc skopiowałem dane. Sementation fault pojawiło się 2 razy, gdy:
- spróbowałem "wymienić" uszkodzony dysk poleceniem btrfs replace.
- Drugi raz spróbowałem wymienić przez dodanie nowego dysku do macierzy (dysk się dodał) i usunąć btrfs device delete missing.
Oba przypadki skończyły się segmentation fault, z tym, że po drugim dysk nie montował się wcale, fs twierdził, że brakuje mu dwóch dysków.

Działo się to jakieś 2 miesiące temu, pod ARCH linuxem, z taką wersją kernela, jaka była wówczas w ARCHu. (System był w pełni aktualny.)

Autor edytował komentarz w dniu: 16.06.2017 13:57
~MacG   5 #37 16.06.2017 14:14

@Meszuge: Bo na windows masz 2-3 systemy plików. Gdzie tak na prawdę korzysta się tylko z jednego słusznego bo wszystko system blokuje. Już nawet pomijam fakt że są to eksponaty muzealne.

Farkas   11 #38 16.06.2017 15:16

@dragon321 no, to w końcu dowiedziałem się, co za tajemnice kryje za sobą ten Btrfs :)

Soren   8 #39 16.06.2017 15:17

Kiedyś na opensuse tumbleweed miałem btrfs na / i po twardym resecie laptopa system nie wstał. Nie jestem pewien czy wywaliłsię system plików na / czy przypadkiem na /boot nie miałem jakiegoś ext2 i czy to on nie zawinił. Spotkałeś się z czymś takim?

Druga sprawa czy da się przenieść zapis migawek na jakiś inny dysk? Mam w lapku ssd i hdd i planuję ten drugi wykorzystać do magazynowania migawek. Naturalnie wtedy na nim też muszę mieć btrfs?

Razi   7 #40 16.06.2017 15:31

@Meszuge: A jakiś inny system przyjmuje chętnie jakieś inne systemy plików?

Meszuge   16 #41 16.06.2017 15:34

@~MacG: Słusznie prawisz. Nowy system plików miał się pojawić wraz z nowym wydaniem systemu Windows, ale...

qbpm   4 #42 16.06.2017 15:35

@Soren: Odnośnie migawek, to nie da się ich przechowywać na innym dysku, bo migawka jako taka, nie zajmuje miejsca. Chyba, że robisz migawkę, kopiujesz ją na inny hdd i usuwasz ze źródłowego dysku, ale wtedy to nie jest migawka tylko kopia migawki.

Juche   5 #43 16.06.2017 17:08

@Apokryf:
@dragon321:
@tomangelo:
A no chyba że tak :)
Faktycznie, na jakimś laptopie z małym SSD to by się opłacało "inwestować" w Btrfs - od jakiegoś czasu mam stacjonarkę (SSD+HDD), pewnie dlatego na to nie wpadłem.
Zwracam honor zatem.

Autor edytował komentarz w dniu: 16.06.2017 17:12
  #44 16.06.2017 17:23

Myślę, że to wystarczający przykład działania subwoluminów!
bullet force multiplayer

wefhy   11 #45 16.06.2017 20:04

@dragon321Bardzo fajny wpis, oby więcej takich :) Ale jak nie masz nic przeciwko, to chciałbym się spytać o 3 rzeczy - migawki katalogów też są, czy tylko całych (sub)wolumenów? Inna sprawa to czy CoW działa tylko przy kopiowaniu na to samo fizyczne urządzenie(żeby nie było problemów przy odłączeniu)? No i ostatie - jeśli płyta główna wspiera RAID sama z siebie to czy jest sens używać tego programowego w btrfs?

KoczurekK   10 #46 16.06.2017 20:34

@qbpm: Segmentation Fault to błąd wyskakujący jak program grzebie w pamięci, w której nie powinien grzebać, nawet prosty kodzik w C++ piszący coś do jakiegoś urządzenia w dev/ może tym sypnąć jak nie dasz mu roota.

To ten, klepałeś polecenia z sudo na początku? :P

qbpm   4 #47 16.06.2017 21:30

@KoczurekK: Nie klepałem sudo, bo jestem leniwy i klepałem jako root. Oto log z operacji:
http://www.wklej.org/hash/621d16e41fb/
tak że to tyle, jeśli chodzi o stabilność tego systemu plików.

dragon321   11 #48 16.06.2017 22:16

@Farkas: Polecam się na przyszłosć :)

@wefhy: Dzięki
1. Nie. Bezpośrednio możesz tworzyć migawki tylko subwoluminów. Możesz natomiast utworzyć subwolumin i zreflinkować do niego wybrany katalog. FAQ o tym mówi:
https://btrfs.wiki.kernel.org/index.php/UseCases#Can_I_take_a_snapshot_of_a_dire...

2. Tym pytaniem mnie trochę zagiąłeś. Nie będę ukrywał - nie mam pojęcia. Ale zaintrygowałeś mnie do sprawdzenia. Podejrzewam, że raczej tak oczywistą sytuacje deweloperzy przewidzieli, ale to tylko moje podejrzenia.

3. Tutaj zależy od sytuacji. Czasami programowy RAID jest bardziej opłacalny, czasem sprzętowy. Tutaj trochę informacji o tym:
https://serverfault.com/questions/685289/software-vs-hardware-raid-performance-a...

@qbpm: Wybacz, ale to było rok temu wnioskując po dacie, jaką mi podałeś w archiwum. Btrfs się ciągle rozwija, nie stoi w miejscu. Próbowałeś w ostatnim czasie? No i inna sprawa, że teraz RAID56 jest oznaczony jako niestabilny - wiem, że wtedy nie był, ale też uważałbym z używaniem świeżych funkcji.

"tak że to tyle, jeśli chodzi o stabilność tego systemu plików."
Nie tego systemu plików, a tej konkretnej funkcji. Btrfs ma trochę więcej funkcji niż tylko ten nieszczęsny RAID56. I pozostałe są stabilne. Nie wydawaj wyroku na cały system plików na podstawie jednej funkcji. To tak jakbyś stwierdził, że samochód nie jeździ poprawnie, bo klimatyzacja jest uszkodzona.

Autor edytował komentarz w dniu: 16.06.2017 22:17
qbpm   4 #49 16.06.2017 22:48

@dragon321: Problem wystąpił miesiąc temu, więc nie tak dawno. Swoją macierz zbudowałem właśnie w styczniu zeszłego roku, kiedy raid5 był uznawany jako stabilny, a pierwszy problem z hdd w tej macierzy wystąpił miesiąc temu, więc dopiero miesiąc temu btrfs miał szanse się wykazać i poległ. Teraz raid5 nie jest uznawany za stabilny. Skąd wiesz, że tylko raid5 był błędnie oznaczony jako stabilny? może czają się inne bugi? Napisałem tak, aby każdy kto testuje ten system plików miał kopie, bo ryzyko utraty danych jest większe niż w innych systemach plików. Po prostu ten system jest zbyt skomplikowany, a jak coś jest tak skomplikowane, to ciężko być pewnym niezawodności. Nadal używam btrfs, bo ma masę zalet, ale zawsze pamiętam o kopii. Musiałem kupić dyski aby odzyskać dane, więc teraz mam gdzie te kopie robić.

dragon321: To tak jakbyś stwierdził, że samochód nie jeździ poprawnie, bo klimatyzacja jest uszkodzona.
Raczej to tak jakby samochód nie skręcał w prawo. Przecież zawsze można skręcić 3 razy w lewo i też się dojedzie.

Co do migawek folderów, to można zrobić "cp -r --reflink" i folder będzie prawie jak migawka.

Autor edytował komentarz w dniu: 16.06.2017 22:50
Lawstorant   8 #50 16.06.2017 23:09

@realkrzysiek: FAT32 zawsze w formie!

wefhy   11 #51 16.06.2017 23:56

@dragon321: Dzięki, przdydatne linki. A to z CoW na różnych urządzeniach już mnie nurtowało od Twojego poprzedniego wpisu, ale nigdzie nie mogłem znaleźć.
Dla mnie sam btrfs miałby fajne zastosowanie, gdyby wszystkie jego dodatkowe funkcje dało się wyłączyć podczas pracy na baterii, a potem po podłączeniu żeby sobie wszystko skompresował, zdeduplikował, uzupełnił itd ;) Bo niestety tu mnie obawa przed szumiącym wentylatorem trochę hamuje. Choć przyznam, że wszystkie te metody oszczędzania przestrzeni kuszą - 275GB SSD to wcale nie jest dużo.

EDIT: Chyba coś znalazłem - przy próbie powinno wyrzucić błąd "Invalid cross-device link". O ile dobrze zrozumiałem tego kogoś(niestety nic oficjalnie) https://lists.fedoraproject.org/pipermail/users/2014-January/445571.html

Autor edytował komentarz w dniu: 17.06.2017 00:03
tylko_prawda   11 #52 16.06.2017 23:59

Blog miesiąca zapewne…
…jak zwykle. :P
Fajny wpis, no i dobrze, że wymieniłeś wady. Na temat samego btrfs się nie wypowiem, bo nie tylko mało o nim wiem, ale i prawie wcale nie miałem z nim do czynienia.
I jak zwykle czekam na kolejny tekst. :)

Autor edytował komentarz w dniu: 17.06.2017 00:00
realkrzysiek   9 #53 17.06.2017 00:41

@Lawstorant: Tylko, że przestarzały. Jeden mały błąd i system nie wstanie. Mogliby dać NTFS, ale po co.

dragon321   11 #54 17.06.2017 00:57

@qbpm: Tak, ale od jakiegoś czasu jest oznaczony jako niestabilny. Wtedy był zapewne poprzez błąd (deweloperzy błędnie uznali, że jest stabilny) - dzisiaj jest wyraźnie zaznaczone, że ta funkcja jest niestabilna i lepiej jej nie używać. Skąd wiem? Bo inne funkcje są dłużej i miały swój czas na przetestowanie. Takie funkcje jak kompresja czy subwoluminy nie są nowinkami w tym systemie plików, dlatego sądzę, że mogę im zaufać. Nigdy nie ufam świeżynkom. Zawsze chwilę czekam. Jak btrfs dorobi się np. szyfrowania czy kompresji lz4 to też się nie rzucę na to odrazu, a poczekam jakiś czas.

Nah nie do końca. Niestabilny RAID w żaden sposób nie ujmuje poprawności innym (STABILNYM) funkcjom tego systemu plików. Da się go używać bez RAID, podobnie jak da się normalnie jeździć samochodem bez klimatyzacji. Przykład który podałeś byłby poprawny, gdyby sypało się coś będące podstawą tego systemu plików (np. gdyby uszkadzał sobie losowo dane przy zapisie). A tak to nie działa jedna z jego licznych funkcji.

Można i tak.

@wefhy: Nie ma sprawy.

Nie masz czego się obawiać. Nie pożera na tyle procesora, by zmuszać go do intensywniejszej pracy. Może oczywiście np. podczas zapisu dużego pliku, ale jak skończy to się uspokoi. Nie monitoruje użycia procesora, ale nie zauważyłem, by jakoś specjalnie dostawał w kość podczas operacji na partycji / (sformatowanej na btrfs). Linux to nie Windows - mielić dyskiem bez wyraźnego powodu nie będzie :)

Ciekawe źródło. Sprawdziłem u siebie i faktycznie cp z opcją reflink nie pozwala mi skopiować pliku pomiędzy dwoma partycjami btrfs z których każda jest na innym urządzeniu. Chociaż to wygląda na pożądane i poprawne działanie. Gdyby Ci pozwoliło skopiować dane techniką CoW na inny nośnik, który byś po tym odłączył, to dane byłyby niepoprawne na tymże nośniku (no bo nie zostały fizycznie skopiowane) i w ten sposób masz blokadę przed zrobieniem tego. CoW pomiędzy różnymi fizycznymi urządzeniami (pomijając RAID) nie ma sensu poprostu.

@tylko_prawda: Dzięki. No cóż, trzeba było wspomnieć o wadach. Nie ma wkońcu ideałów :)

Autor edytował komentarz w dniu: 17.06.2017 00:57
dragon321   11 #55 17.06.2017 01:00

@realkrzysiek: "Mogliby dać NTFS, ale po co"

Biorąc pod uwagę to, w jakim stopniu wspierany jest NTFS na czymś innym niż Windows, to już lepszy jest ten FAT32.

dragon321   11 #56 17.06.2017 01:11

@Soren: Nie. Mam 2 partycje - / na btrfs i /home na ext4 (teraz żałuję, że nie dałem xfs, a nie chce mi się tego przenosić już) i obie stoją pomimo kilkukrotnego siłowego wyłączenia komputera. Żadna nie przejawia jakichkolwiek oznak uszkodzenia.

Nie próbowałem, aczkolwiek tutaj jest poradnik o tym traktujący (z wykorzystaniem btrfs send i btrfs receive):
https://www.kubuntuforums.net/showthread.php?t=67487

Tak, musisz mieć tam btrfs. Tak więc da się, chociaż trochę z tym roboty jest (w przypadku potrzeby przywrócenia migawki musisz ją spowrotem przenieść na pierwotną partycje).

wefhy   11 #57 17.06.2017 01:12

@dragon321: Obawa to obawa, nie ma testów to nie ma pewności :P A tak na logikę - gdyby nie nadużywał procesora to w teorii powinien szybszy, nie wolniejszy od ext4(bo fizycznie zapisuje mniej danych) - a że ja walczę o każdą minutę z bajerami jak TLP(to jest coś, z 3.5h zrobiło 5 bez konfigu - https://wiki.archlinux.org/index.php/TLP ), to... może jak załatwię powerbanka do laptopa(ogniwa już są i czekają na zlutowanie) ;)

dragon321   11 #58 17.06.2017 01:17

@wefhy: Podczas zapisu napewno bardziej używa procesora niż ext. Ale Linux to Linux - on sam z siebie nie mieli dyskiem. Raczej na partycji / nie masz za dużo operacji do robienia, a przynajmniej nie na okrągło. A odczyt nie powinien się dużo różnić od ext. A na /home mam ext4, bo tam się dzieje najwięcej :)

Oh, zabawne, że nawet nie mam tlp. Musze je sobie zainstalować.

Lawstorant   8 #59 17.06.2017 09:59

@realkrzysiek: to była ironia. Nie dość że system plików stary to jeszcze własnościowy! Super, tak samo lepiej jakby karty SDXC były na czymś innym niż exFAT no ale po co...

ra-v   13 #60 17.06.2017 18:55

Miałem, używałem, wróciłem. Błędy popełnia każdy.
Na lapku i na PC na SSD rozłożył mnie błąd "no space left on device". W Google znajdzie się oczywiście masa poradników dotyczących rozwiązania problemu i "tuningu" btrfs-a, każdy bardzo podobny, które i tak nie rozwiązały problemu. Btrfs jakoś dziwnie zarządza metadanymi. Jeszcze tak dziwnego systemu plików nie widziałem.

Najpierw spotkałem się z tym problemem w PC, potem w lapku, co gorsza, w przeddzień kiedy akurat był potrzebny. W takiej sytuacji można się wku... na takie coś. Albo w sumie na siebie, że zacząłem kombinować z tym, co wielce "polecali" na forach.

Oczywiście wróciłem do niezniszczalnego ext4. Nauczka na przyszłość - chce się mieć system zniszczalny tylko i wyłącznie przez czołg, to się nie kombinuje.

Berion   15 #61 17.06.2017 21:32

@realkrzysiek: I kto by płacił za ten NTFS? Ja bym na pewno nie chciał, a MS za darmo nie dał by licencji producentom laptopów... Najlepszym kandydatem dla partycji EFI byłby F2FS.

@Lawstorant Karta pamięci może mieć dowolny system plików, który zależy od Ciebie, a nie producenta. Ale rozumiem, że to był skrót myślowy i po prostu firmware np. aparatu wymaga exFAT bo nic innego nie obsługuje, więc siłą rzeczy wymusza na Tobie ten konkretny fs na tej karcie, którą używa wspomniany aparat. ;]

@ra-v EXT4 i niezniszczalny to oksymoron.

Autor edytował komentarz w dniu: 17.06.2017 21:37
realkrzysiek   9 #62 17.06.2017 21:45

@Berion: Oczywiście, że chciałbym inny system plików, ale i tak uważam za niepoważne używanie systemu FAT.

Berion   15 #63 17.06.2017 21:47

@realkrzysiek: Ja także tak uważam. :)

dragon321   11 #64 17.06.2017 22:07

@ra-v: "Na lapku i na PC na SSD rozłożył mnie błąd "no space left on device"."

To nie tyle błąd Btrfs co po prostu programy często mają problem z ogarnięciem jego innej i bardziej skomplikowanej natury. Choćby Steam - do pewnego czasu (albo i nadal, nie mam pojęcia czy to poprawili) za nic nie pozwolił Ci stworzyć biblioteki na ZFS czy Btrfs - wywalał błąd, że za mało miejsca ma.

@Berion: Oh, ale FAT też jest opatentowany. Ponoć właśnie to jeden z patentów używanych przez Androida, za które muszą płacić Microsoftowi wydając urządzenia z tym systemem. :)

Tak czy siak lepiej że jest to jednak FAT niż NTFS, bo ten drugi po prostu nie jest za dobrze obsługiwany poza Windowsem. Oczywiście, wspomniany F2FS byłby znacznie lepszy (podobnie jak na kartach pamięci w wyżej wspomnianym Androidzie), ale ze wzgląd na kompatybilność z Windowsem używa się takich systemów plików z ubiegłego stulecia. A Microsoft nie dopuści obsługi F2FS do Windowsa właśnie dlatego, że nienajgorzej zarabia na patentach.

hiropter   11 #65 18.06.2017 00:20

"(...)To nie tyle błąd Btrfs co po prostu programy często mają problem z ogarnięciem jego innej i bardziej skomplikowanej natury. Choćby Steam - do pewnego czasu (albo i nadal, nie mam pojęcia czy to poprawili) za nic nie pozwolił Ci stworzyć biblioteki na ZFS czy Btrfs - wywalał błąd, że za mało miejsca ma.(...)" - po prostu mało programów dobrze jeszcze obsługuje ten system plików. Praktycznie żadne typowe narzędzie (np.: ls, du) nie potrafi pokazać ile faktycznie pliki zajmują na dysku i podejrzewam jeszcze sporo wody w Wiśle upłynie nim ich opiekunowie zaimplementują odpowiednie funkcje.

Berion   15 #66 18.06.2017 00:21

@dragon321: Pierwsze słyszę, nie pomyliłeś z exFAT/TexFAT?

hiropter   11 #67 18.06.2017 00:25

@ra-v: Btrfs jest całkiem miłym systemem plików, ale jego główne zalety sprawdzają się tylko na serwerach, a nie na komputerach domowych. W domu co prawda mam tylko Windowsa, ale gdyby miał już postawić Linuksa, to na laptopa pewnie trafiłbym XFS, a na stacjonarkę pewnie trafiłby EXT4 - z racji lepszej odporności na pady wywołane brakiem zasilania.

charper   9 #68 18.06.2017 01:50

@realkrzysiek: okna w domu to tez przeżytek w sumie.

realkrzysiek   9 #69 18.06.2017 06:41

@hiropter: Mam na partycji systemowej i nie zauważyłem żadnych problemów. Zanim powstało ext4 używałem Reiserfs, a teraz przechodzę na btrfs.

Autor edytował komentarz w dniu: 18.06.2017 06:45
realkrzysiek   9 #70 18.06.2017 06:45

@charper: Okna, jak to okna, a przecież możemy mieć szyby z miki, a nie tam nowoczesne , wzmocnione, antywłamaniowe, a nawet kuloodporne. :)

stasinek   12 #71 18.06.2017 08:14

@dragon321: Patent na długie nazwy w FAT wygasł w 2014r dlatego zawczasu Microsoft wymyślił exFAT, sztucznie limitował ograniczenie pojemności FAT32 w Windows aby wywołać wrażenie że dni FAT32 są policzone, zapłacił komu trzeba https://www.sdcard.org/about_sda/index.html i odcina kupony :)

exFAT konstrukcyjnie tkwi w latach 90, badziewie pisane na kolanie, poza brakiem dziennika, brakuje mu narzędzi do odzyskiwania danych. Jeśli tylko można na pendrajwie, dysku przenośnym najlepiej sie sprawdza NTFS. Dziennik, wbudowana kompresja, masa narzedzi. Jeśli nie ma opcji FAT32 bo obsługuje 2TB i również jest zgodny praktycznie z każdym systemem operacyjnym i każdym urządzeniem. Problemem jest limit na rozmiar pliku.

Autor edytował komentarz w dniu: 18.06.2017 08:38
ra-v   13 #72 18.06.2017 12:21

@hiropter:
BTRFS chyba był nawet domyślnie proponowany w openSUSE.

ra-v   13 #73 18.06.2017 12:22

@dragon321:
Programy działają na wyższej warstwie.

  #74 18.06.2017 14:02

@charper: Tak, dlatego używanie Windowa to przeżytek :)

dragon321   11 #75 18.06.2017 14:12

@Berion: Możliwe, nie wiem czy to dotyczy tylko exFAT, czy ma też oparcie na FAT32:
http://en.swpat.org/wiki/Microsoft_FAT_patents

@hiropter: No właśnie. Ten system plików w stosunku do poprzednich to dość spory skok. Coś jak Wayland i X11. Trochę upłynie zanim wszystko będzie go ogarniać bez bólu.

"ale jego główne zalety sprawdzają się tylko na serwerach, a nie na komputerach domowych"
A ja myślę, że kompresja czy migawki to jak najbardziej funkcje przydatne w domu. Jak dojdzie jeszcze szyfrowanie to też będzie to funkcja przydatna na domowym sprzęcie (no bardziej laptopie).

@stasinek: Możliwe, mogłem się pomylić.

exFAT wygląda na to, że jest przypudrowaniem FAT32 i zdjęciem niektórych jego ograniczeń. Design jednak nadal jest ten sam. O co bardziej zaawansowanych funkcjach można pomarzyć.

@ra-v: Mówimy o programach, które m.in. sprawdzają ilosć miejsca na partycji. One mają problem z Btrfs, bo ten bazuje na innej logice i jest inaczej zbudowany niż inne Linuksowe systemy plików. Nawet na wiki Btrfs jest napisane, żeby nie ufać narzędziu df, bo wyniki mogą być błędne.

gadatos   3 #76 18.06.2017 15:06

Też używałem i nie miałem z nim problemów, system po prostu działa.

sr57be45   7 #77 19.06.2017 00:22

Jako zwykły użytkownik patrząc na testy szybkości wybrałem kiedyś jfs i faktycznie na wolnym dysku ATA66 było szybciej. Problem był gdy chciałem coś skopiować z poziomu Windows, Program wspierał ext/xfs ale nie jfs.

ra-v   13 #78 19.06.2017 12:02

@dragon321: ale nie z tym był problem. Wpisz "BTRFS no space left on device" w Google to zobaczysz o co chodzi.

dragon321   11 #79 19.06.2017 13:00

@ra-v: Z tego co tam jest napisane, to był to błąd w kernelach 3.x, który został naprawiony.

kilijanek   9 #80 19.06.2017 17:14

@dragon321: exFAT jest czymś więcej niż kolejną zmianą z FAT16 na FAT32.
Ma np. journaling i kilka innych ciekawych elementów. No i licencja na niego jest trochę inna niż na FAT32.

Btrfs jest nowy.. choć ciągle goni króliczka: ZFS...

kilijanek   9 #81 19.06.2017 17:24

@stasinek: Najpierw zapoznaj się z możliwościami exFAT, bo to co napisałeś... to pomijasz pre-alokację zasobów, uprawnienia do plików i katalogów, a także monitorowanie checksum, a także to, że ten system jest dostosowany do pamięci flash - jak F2FS. Nazywanie tego czymś słabym jest nieporozumieniem, zwłaszcza, jak spojrzysz na np. systemy Apple, które używają HFS+ (systemu plików, który ledwie konkuruje z FAT32).

ra-v   13 #82 19.06.2017 20:02

@dragon321:
W openSUSE 42.2 nie ma 3.x, a ja downgrade nie robiłem.

  #83 20.06.2017 21:01

@yy (niezalogowany): "system przede wszystkim nie ma trudnej historii jak reiser4

"

Tak, nie wsadzili jego twórcy do więzienia za zabójstwo żony :)

ilili   9 #84 21.06.2017 13:40

@dragon321 "Niestety licencja ZFS (CDDL) uniemożliwia bezpośrednie włączenie jego kodu bezpośrednio do jądra Linux."

Chyba odwrotnie, licencja CDDL zezwala na łączenie kodu z dowolną inną licencją. To GPL nie zezwala na dołączanie kodu innego niż GPL lub licencje równoważne.

saitoh   6 #85 21.06.2017 16:10

@ilili: "Chyba odwrotnie, licencja CDDL zezwala na łączenie kodu z dowolną inną licencją. To GPL nie zezwala na dołączanie kodu innego niż GPL lub licencje równoważne."

Bzura. Te licencje są po prostu niekompatybilne.
I był to celowy wybór deweloperów ZFS (dokładniej OpenSolarisa) by nie dało się kodu na licencji CDDL łączyć z GPL.

"According to Danese Cooper one of the reasons for basing the CDDL on the Mozilla license was that the Mozilla license is GPL-incompatible. Cooper stated, at the 6th annual Debian conference, that the engineers who had written the Solaris kernel requested that the license of OpenSolaris be GPL-incompatible."

ilili   9 #86 21.06.2017 16:32

@saitoh: "Bzura."

Faktycznie licencja CDDL, co prawda zezwala na dołączanie do innych projektów (innych licencji) ale tylko binarnej wersji, kod źródłowy musi pozostać na CDDL, jeśli jest dołączany, bo jeśli projekt nie jest open source i nie dystrybuuje własnego źródła do nie ma problemu w dodawaniu do niego kodu CDDL... Polska wikipedia wprowadziła mnie w błąd...

charper   9 #87 22.06.2017 01:44

@Anonim (niezalogowany): ciekawe czy inne rzeczy tez wolisz miec wykastrowane ;)

dragon321   11 #88 22.06.2017 11:35

@kilijanek: Jest też swoistą bombą patentową. Nie da się z niego sensownie korzystać nie płacąc "haraczu". Zresztą jak każdy system plików od Microsoftu.

Byłoby miło, jakby wszyscy producenci zdecydowali się na jakiś otwarty i wolny system plików (np. F2FS) i olali Microsoftowe twory. To by ich przymusiło do wsparcia standardu.

@ra-v: To może być albo błąd w kernelu, albo poprostu program nie ogarnia btrfs. Z ZFS podobne problemy czasem są.

@ilili: Nie zrozumiałeś sensu tego zdania. Chodzi w nim o to, że licencja na jakiej jest ZFS uniemożliwia bezpośrednie włączenie go do jądra na GPL. Nigdzie nie zasugerowałem, że to CDDL jest niezgodne z GPL, bo wiem, że jest odwrotnie :)

  #89 22.06.2017 16:21

@charper: "ciekawe czy inne rzeczy tez wolisz miec wykastrowane "

Sporo o tym wiesz jak na użytkownika Win10 przystało :D

  #90 06.07.2017 19:47

@wielkipiec: dragon321:

P.S. Akurat Alec Guinness nie lubił Gwiezdnych Wojen i uważał je za "głupią bajeczkę"... ;)

  #91 06.07.2017 19:52

@dragon321:
P.S. Akurat Alec Guinness nie lubił Gwiezdnych Wojen i uważał je za "głupią bajeczkę"...

wielkipiec   16 #92 07.07.2017 11:32

@Hodor (niezalogowany): ale zagrał świetnie :) Zresztą MacGregor też

dragon321   11 #93 07.07.2017 17:27

@Hodor (niezalogowany): Harrison Ford też i co? Nie zmienia to faktu, że obaj świetnie zagrali. Wspomniany Ford chciał jakąś niewielką rolę, a dostał rolę jednej z najważniejszych postaci w Oryginalnej Trylogii. Chciał też uśmiercenia swojej postaci, czego doczekał się dopiero w Trylogii Sequeli :)

@wielkipiec: Dokładnie. Żywiołowy MacGregor jako młody ObiWan i poważny Guinness jako starszy Ben. Obaj dobrze pasowali do swoich ról i obaj dobrze zagrali. :)

wielkipiec   16 #94 07.07.2017 19:26

@dragon321: Czyż nie? Oglądając młodego MacGregora, widać Obi-Wana. A więc doskonale się uzupełnili ! ??

dragon321   11 #95 07.07.2017 20:11

@wielkipiec: Ano właśnie :)

Gratulacje!

znalezione maszynki:

Twój czas:

Ogól Naczelnego!
Znalazłeś(aś) 10 maszynek Wilkinson Sword
oraz ogoliłeś(aś) naszego naczelnego!
Przejdź do rankingu
Podpowiedź: Przyciśnij lewy przycisk myszki i poruszaj nią, aby ogolić brodę.