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
836
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
Hengenvaaralliset kiihdytysajot päättyivät karmealla tavalla, kilpailija kuoli
Onnettomuudesta on aloitettu selvitys. Tapahtuma keskeytettiin onnettomuuteen. Tapahtumaa tutkitaan paikan päällä yhtei1986908- 1592036
- 1131688
- 511390
Suureksi onneksesi on myönnettävä
Että olen nyt sitten mennyt rakastumaan sinuun. Ei tässä mitään, olen kärsivällinen ❤️551238Möykkähulluus vaati kuolonuhrin
Nuori elämä menettiin täysin turhaan tällä järjettömyydellä! Toivottavasti näitä ei enää koskaan nähdä Kauhavalla! 😢501098Älä mies pidä mua pettäjänä
En petä ketään. Älä mies ajattele niin. Anteeksi että ihastuin suhun varattuna. Pettänyt en ole koskaan ketään vaikka hu1001074Reeniähororeeniä
Helvetillisen vaikeaa työskennellä hoitajana,kun ei kestä silmissään yhtään läskiä. Saati hoitaa sellaista. Mitä tehdä?7996Tarvitsemme lisää maahanmuuttoa.
Väestö eläköityy, eli tarvitsemme lisää tekeviä käsiä ja veronmaksajia. Ainut ratkaisu löytyy maahanmuutosta. Nimenomaan251954- 41929