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
605
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
Huumekohussa marinoitu Redrama Vain elämää -kuvauksista: "...valehtelevan, jos sanoo, ettei..."
Juhannuksen jälkeen Redrama oli aiheuttanut lähipiirissään huolta kuukauden mittaisella katoamistempullaan. Vain elämää -leiri pidettiin toukokuun lop83092- 1672853
Isosisko ajoi 1 vuotiaan kuoliaaksi Tyrnävällä, olivatko Lestoja ?
Eikö tämä laiton lahko voitaisi jo julistaa täysin rikolliseksi ja kieltää laissa, kuten kaikki muukin vahingollinen lopetetaan ? Tämä lapsia tuhoava1042327Ohhoh! Michele Murphy-Kaulanen hämmentää vauvauutisella - Totuus on hieman toisenlainen!
No nyt on aikamoinen "vauva"! Michele Minttu Murphy-Kaulanen on jakanut Instassa "iloisen perhetapahtuman". Lue juttu ja katso kuvat: https://www.su151761Kuu kaipaa tähtiään...
mutta nalle kaipaa tähtisilmäänsä vielä enemmän. Runoa ei täksi illaksi viel ole, mut toivottavasti pidät tästä laulusta :) olen vähä epävarma onko tä1711016Kerran vielä...
Minä tiedän ja sinä tiedät...Anteeks omasta puolesta🤗... toivon oikeasti sulle kaikkea hyvää, vaikka viisaasti et toiminutkaan, mutta mä alan olla ta53979Sanna on aivan sekaisin Venäjästä, auringonpistosko?
Sannan mielestä tavallinen venäläinen ei saisi matkustaa Euroopassa ja käydä katsomassa nähtävyyksiä. Tällä hetkellä hävettää olla suomalainen, niin t246840- 33829
Miksei Martinaa kutsuttu Leppilampi en häihin
Pelättiin varmasti että jos käyttää siellä "äidillisiä otteita" muihin vieraisiin tai nuolee jonkun miehen korvaa.58813Mies, kudoin sulle villahaalarin
Sellasen kirjavan, jossa on huppu ja avattava lappu takalistossa. Laitathan sitten joka päivä sen töihin. ☺️110739