LUKS ja XFS on osoittautunut vuosien saatossa erittäin luotettavaksi yhdistelmäksi.
Nyt on uusi datalevy bittimössöytymässä ja olen googletellu siirtymistä yhdistelmään LUKS2 ja btrfs. Googlettelun tulos kyllä antaa asiasta melko hyvät arvosanat. Toisaalta btrfs ei taida olla oletustiedostojärjestelmä vielä missään Linux-jakelussa. Onko kenelläkän kokemuksia asiasta?
Toinen hieman epäselvä asia on sektorin koko. Sisäisesti levyn sektorikoko on 4k Onko hyötyä antaa salaukselle ja tiedostojärjestelmälle sektorin kooksi 4k?
LUKS ja XFS vai LUKS2 ja btrfs
Anonyymi
15
885
Vastaukset
- Anonyymi
btrfs on oletuksena Fedora 33, ja varmaan siitä eteenpäin.
Monta kertaa olen XFS yrittänyt, mutta jostain syystä saanut sen aina kurttuun, eli olen suosiolla pitäytynyt vain EXT4 ja LUKS.
Eli, kyllä, tunnustan avoimesti että en osaa käyttää ja parametroida tai konfiguroida XFS siten että se toimisi luotettavasti omassa ympäristössäni.
btrfs on tuossa julkaisussa myös jotekin 'universaali', eli enää ei tarvitse käyttää LVM lainkaan, koska siihen sisältyy samantyyppiset toiminteet, eli paljon uutta opeteltavaa olisi taas.
Itse aion kuitenkin edelleen pitäytyä LVM ja EXT4, että seurata kirjoittelua aiheesta kunhan btrfs saa tässä enemmän jalansijaa ja käyttäjiä, että myös artikkeleita ja kirjoituksia eri foorumeilla.
Eli, jos koneellasi on kaikkea tärkeää, kuten minulla, koska teen aivan kaiken Linuxilla, niin ota varman päälle, äläkä lähde 'vähän kokeilemaan'.
Virtuaalikoneissa voi kokeilla ja harjoitella.- Anonyymi
Mulla on harjoittelua varten kone ja muutama kovalevy.
- Anonyymi
Anonyymi kirjoitti:
Mulla on harjoittelua varten kone ja muutama kovalevy.
Aina tottakai tehokkaampaa natiivisti kuin verrattuna virtuaaliseen.
- Anonyymi
Tiedostojärjestelmän blokin koko määrää myös sen että kuinka monta tiedostoa sinne sitten mahtuu.
Jos tarkoitus on tallettaa paljon isoja tiedostoja (videot tms), niin voi käyttää blokkikokoa 16k - 32k.
Musiikille mitä tahansa välillä 4k, 8k tai ehkä jopa 16k.
Virtuaalikoneille ja muille todella isoille vastaaville dataosiolle (levyimaget, .iso -imaget) voi käyttää jopa 64k, koska levyimageja muodostettaessa niiden koon voi määrittää suoraan sopivaan jaolliseen lukuun, niin tällöin ei mene yhtään tilaa hukkaan.
Pitää muistaa, että aina kun tiedostojärjestelmään luo tiedoston, ja vaikka sen koko/pituus olisi vain yksi (1) merkki/tavu, niin se silti allokoi yhden kokonaisen blokin.
Jos siis blokkikoko olisi vaikka 64k, niin tiedostojärjestelmän vapaa tila kevenee heti välittömästi 64k, vaikka tekisi vain tiedoston jossa vain 1 merkki.
Pitää myös muistaa, että osio pitää erikseen alustaa salaukselle, eli LUKSin käyttöön, jolloin kaikki tuolla osiolla mahdollisesti jo olevat tiedostot tuhoutuvat.
Tämän jälkeen se pitää sitten erikseen ottaa käyttöön varsinaisen tiedostojärjestelmän luontia varten, mihin pätevät aivan samat säännöt kuin tavalliseenkin osioon.
Monet tiedostojärjestelmiin liittyvät työkalut osaavat nykyään ottaa automaattisesti huomioon myös salatun osion, ja toimivat tämän kanssa suoraan, kysyen aina salasanaa tarpeen vaatiessa toimintojen jatkamiseksi tai loppuun saattamiseksi.
Eli, kyllä, myös RAIDin voi salakirjoittaa.- Anonyymi
Nettiä kaivellessa tein seuraavan huomion. Tiedostojärjestelmälle sektorin koko on eri asia kuin varausyksikön koko. Kun on sellainen levy, jossa fyysinen sektorin koko on 4k ja looginen sektori 512 tavua niin sekä tiedostojärjestelmän että LUKSin optioksi kannattaa laittaa että sektorin koko on 4k. Hyötyä lupaavat vasta kovassa kuormituksessa koska levyn ohjaulogiikka osaa hyödyntää luppoaikaa.
Btrfs ei näytä tarjoavan mitään lisäetua mikäli sen erikoisominaisuuksille ole käyttöä. - Anonyymi
Anonyymi kirjoitti:
Nettiä kaivellessa tein seuraavan huomion. Tiedostojärjestelmälle sektorin koko on eri asia kuin varausyksikön koko. Kun on sellainen levy, jossa fyysinen sektorin koko on 4k ja looginen sektori 512 tavua niin sekä tiedostojärjestelmän että LUKSin optioksi kannattaa laittaa että sektorin koko on 4k. Hyötyä lupaavat vasta kovassa kuormituksessa koska levyn ohjaulogiikka osaa hyödyntää luppoaikaa.
Btrfs ei näytä tarjoavan mitään lisäetua mikäli sen erikoisominaisuuksille ole käyttöä.Kyllä, varausyksikön koko, eli siis 'block size' todellakin on eri kuin sektorin koko.
4k on yleisimmin, ja käytännössä aina käytetty koko koska se on oletusarvo, mutta sitä voi toki muuttaa jos katsoo että sille on tarvetta tai jos siitä muuten olisi odotettavissa jotain hyötyä.
Tuo 'kova kuormitus' koskee ilmeisesti vain ja ainoastaan palvelimia, joissa käytetään muttenkin nopeita SAS tai SCSI -levyjä; kotikäytössä kaikki 'kuormitus' vain hidastaa koko konetta koska SATA -väylä ei todellakaan ole mitenkään 'nopea' verrattuna SAS ja SCSI.
Olen samaa mieltä kanssasi tuosta Btrfs:stä, että se ei todellakaan ...'näytä tarjoavan mitään lisäetua mikäli sen erikoisominaisuuksille ole käyttöä.'... - Anonyymi
Anonyymi kirjoitti:
Kyllä, varausyksikön koko, eli siis 'block size' todellakin on eri kuin sektorin koko.
4k on yleisimmin, ja käytännössä aina käytetty koko koska se on oletusarvo, mutta sitä voi toki muuttaa jos katsoo että sille on tarvetta tai jos siitä muuten olisi odotettavissa jotain hyötyä.
Tuo 'kova kuormitus' koskee ilmeisesti vain ja ainoastaan palvelimia, joissa käytetään muttenkin nopeita SAS tai SCSI -levyjä; kotikäytössä kaikki 'kuormitus' vain hidastaa koko konetta koska SATA -väylä ei todellakaan ole mitenkään 'nopea' verrattuna SAS ja SCSI.
Olen samaa mieltä kanssasi tuosta Btrfs:stä, että se ei todellakaan ...'näytä tarjoavan mitään lisäetua mikäli sen erikoisominaisuuksille ole käyttöä.'...Jos nopeutta hakee ja sitä tarvitsee viimeisetkin rippeet, XFS on ehdoton valinta. Sen sijaan jos levyllä on monta kopioimalla tehtyä koodipuuta, esim. linux-kerneliä, tarjoaa btrfs huomattavan tilansäästön, koska pelkästään muutokset tiedostoihin sektoritasolla talletetaan oikeaksi kopioksi. Ja kyllä, tämä aiheuttaa joissakin tilanteissa btrfs:n melkoista hidastelua. Hidastelua voi vähän kompensoida käyttämällä lzo-kompressiota. Varsinkin useamman coren koneissa tuo levyn pakkaaminen menee käytännössä taustalla ja levy tuntuu nopealta. Nopeuksissa sanoisin, että ext4:ään tottuneena btrfs tuntuu välillä takkuavan, mutta toisaalta pakkauksen kanssa tilaa on järjettömästi enemmän. Sitä ei usko ennen kuin koodipuun koko on gigatavuja ja siitä on sata kopiota järjestelmässä, jossa levyllä on tilaa 80 gigaa.
- Anonyymi
Anonyymi kirjoitti:
Jos nopeutta hakee ja sitä tarvitsee viimeisetkin rippeet, XFS on ehdoton valinta. Sen sijaan jos levyllä on monta kopioimalla tehtyä koodipuuta, esim. linux-kerneliä, tarjoaa btrfs huomattavan tilansäästön, koska pelkästään muutokset tiedostoihin sektoritasolla talletetaan oikeaksi kopioksi. Ja kyllä, tämä aiheuttaa joissakin tilanteissa btrfs:n melkoista hidastelua. Hidastelua voi vähän kompensoida käyttämällä lzo-kompressiota. Varsinkin useamman coren koneissa tuo levyn pakkaaminen menee käytännössä taustalla ja levy tuntuu nopealta. Nopeuksissa sanoisin, että ext4:ään tottuneena btrfs tuntuu välillä takkuavan, mutta toisaalta pakkauksen kanssa tilaa on järjettömästi enemmän. Sitä ei usko ennen kuin koodipuun koko on gigatavuja ja siitä on sata kopiota järjestelmässä, jossa levyllä on tilaa 80 gigaa.
BTRFS tIMESHIFT -yhdistelmä on myös ilmeisesti hyvä juuri tuon takia. Timeshiftissähän snapshotin tekotavaksi voi valita joko rsync tai BTRFS -tavan.
T. miksuh - Anonyymi
Anonyymi kirjoitti:
Jos nopeutta hakee ja sitä tarvitsee viimeisetkin rippeet, XFS on ehdoton valinta. Sen sijaan jos levyllä on monta kopioimalla tehtyä koodipuuta, esim. linux-kerneliä, tarjoaa btrfs huomattavan tilansäästön, koska pelkästään muutokset tiedostoihin sektoritasolla talletetaan oikeaksi kopioksi. Ja kyllä, tämä aiheuttaa joissakin tilanteissa btrfs:n melkoista hidastelua. Hidastelua voi vähän kompensoida käyttämällä lzo-kompressiota. Varsinkin useamman coren koneissa tuo levyn pakkaaminen menee käytännössä taustalla ja levy tuntuu nopealta. Nopeuksissa sanoisin, että ext4:ään tottuneena btrfs tuntuu välillä takkuavan, mutta toisaalta pakkauksen kanssa tilaa on järjettömästi enemmän. Sitä ei usko ennen kuin koodipuun koko on gigatavuja ja siitä on sata kopiota järjestelmässä, jossa levyllä on tilaa 80 gigaa.
Nähdäkseni XFS ei ole mikään "ehdoton valinta" silloin kun käyttää SATA -levyjä, koska väylä tulee pullonkaulaksi joka tapauksessa.
Itsekin kikkailen RAM -levyn kassa juuri tästä syystä, koska sitä käyttämällä voi todellakin nopeuttaa monia asioita huomattavasti. - Anonyymi
Anonyymi kirjoitti:
BTRFS tIMESHIFT -yhdistelmä on myös ilmeisesti hyvä juuri tuon takia. Timeshiftissähän snapshotin tekotavaksi voi valita joko rsync tai BTRFS -tavan.
T. miksuhLVM tukee myös snapshotteja ja siihen voi konfiguroida myös erillisen tiedostojen palautusominaisuuden vahingossa poistetuille tiedostoille, jos snapshotteja ei halua käyttää...
- Anonyymi
Heitä jo tuommoinen linkkura hitolle!
- Anonyymi
Lapset hiljaa! Nyt puhutaan miesten asioista.
- Anonyymi
btrfs on myös openSusen oletus nykyään.
Eipä tuo ole hisdastellut, eikä takkuillut. Luxsia en ole toistaiseksi nähnyt. Itsellä ollut XFS käytössä vuosia. Hyvä varsinkin suurille tiedostoille joita tulee kun kone tallentaa TV-ohjelmia. Pakkaamisesta ei hyotyä kun on jo pakattua kamaa. Sama valokuvissa. Etu myös kun XFS levyä ei tarkisteta automaattisesti. iso Ext4 levyn tarkistus kestää ja hyvä noita välillä tarkistella. Vaikka kerran kuussa.
Kernelin lähdepuu on melkoinen. Itsellä ihan ext4 levyllä ja käännän usein ram-levyllä jolloin käännös ei kovin kauaa kestä. Ainakin väliaikaistiedostot muistiin. gcc bootstrap ja moni muu isompi käännös inhottavia kun eivät mahdu enää itsellä keskusmuistiin. Siinä pakkaamisessa olisi ehkä hyötyä, mutta nopeuden kustannuksella.- Anonyymi
EXT4 -osion tarkistusaika riippuu siitä että kuinka paljon muutoksia tiedostojärjestelmässä on ollut, koska se varmentaa kaikki 'inode't, ja tutkii että voiko tarpeettomia ottaa kokonaan pois käytöstä.
EXT4 -tarkistus ei ole mitään verrattuna ison RAID -pakan tarkistukeen, jossa saattaa menee helposti koko yö...
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Säästäminen on typerää, muistakaa äänestää demareita
Säästäminen on typerää, koska aiheuttaa vain talouden taantumista ja lopulta tappaa potilaan. Demareiden tapa on satsat1057846Olli Rehn: Eläkkeistä pitää leikata. Nyt tuli Lindtmanille kauhun paikka
jos johtaa seuraavaa hallitusta. Purra: eläkkeisiin ei kosketa. Eikä tällä hallituskaudella varmasti kosketa, mutta seur4186984SDP:n budjetin peruskivi: "Rahaa nimittäin on!"
Demarien talouspolitiikan ydin on usein tiivistetty klassiseen meemiin: rahaa on, kunhan se on jonkun muun rahaa. Vuoden1685254Poliisien suosikkipuolueet ylivoimaisesti: Kokoomus ja persut
samoin on armeijan henkilöstön kanssa. Sen sijaan sekä vihreät, vasliitto ja SDP ovat hyljeksittyjä puolueita poliisien1034175Sdp, Vihreät ja vasemmistoliitto muuttumassa naisten puolueiksi?
Sdp 64 % naisia, vihreät 70 % naisia ja vasemmistoliitto 60 % naisia. Ilmankos ne puolueet ajaa autoilevien kantasuomal954086Kun täällä kysytään aina vaan naisilta
Niin nyt kysytään miehiltä. Mies, voisitko ottaa kumppaniksesi naisen joka nostaa enemmän penkistä kuin sinä? Tienaa en734082Hatunnosto! Mari Hynynen (os. Perankoski) ja Jouni Hynynen auttavat vähäosaisia upealla tavalla!
Hatunnosto! Mari ja Jouni Hynynen ovat Vailla vakinaista asuntoa ry:n uudet kummit. Hynysiä motivoi halu lisätä ymmärr103822Tiesitkö? Tämä suomalainen keksi Elämäni biisi -sarjan - Viinin lipittely mainittu!
Tiesitkö? Elämäni biisi on suomalainen formaatti ja sen takana on Petja Peltomaa. Hänen kynästä ovat lähtöisin myös mm.03510Epäonnistunut "Tuppurais-operaatio" kaatoi Purran hallituksen
Persut yrittivät viimemetreillä häivyttää omaa täydellistä epäonnistumistaan syyttämällä opposition edustajaa nimettömil132370Ostaisitko sinä rempattavan asunnon Italiasta tai jostain muualta ulkomailta, mistä?
Ella Kanninen on tehnyt Italiassa asuntokaupat. Hän kertoo Instagramissa kierrelleensä viime kesänä Toscanassa katselema161949