Kirjoittaja Aihe: Levy I/O ja tiedosto operaatiot Windows vs Ubuntu  (Luettu 12842 kertaa)

Tomin

  • Palvelimen ylläpitäjä
  • Käyttäjä / moderaattori+
  • Viestejä: 11481
    • Profiili
    • Tomin kotisivut
Vs: Levy I/O ja tiedosto operaatiot Windows vs Ubuntu
« Vastaus #20 : 13.05.08 - klo:21.51 »
http://brainstorm.ubuntu.com/idea/6325/ (graafinen disk check) - sanotaan että Hardyssa olisi toteutettu. Kubuntu-puolella ei ainakaan, liekö sitten Ubussa vain.. Ja tähän liittyen tuolla oli joskus idea että pitäisi olla keskeytettävissä/skipattavissa ja mielestäni siitäkin sanottiin että hardyyn tulee mutta en siitä sitten tiedä.
Juu kyllä sen voi skipata escillä. Siinä vielä sanotaan (ainakin jos on splash käytössä) siitä. En ole kokeillut vaan antanut aina mennä.
Automaattinen allekirjoitus:
Lisäisitkö [RATKAISTU] ketjun ensimmäisen viestin aiheeseen ongelman ratkettua, kiitos.

Timo Jyrinki

  • Sr. Member
  • ****
  • Viestejä: 1260
    • Profiili
    • kotisivu
Vs: Levy I/O ja tiedostojärjestelmät
« Vastaus #21 : 13.05.08 - klo:22.47 »
Kuitenkin se häviää selvästi...

Oletko nähnyt real-world-benchmarkkeja viime aikoina? Useimmat näkemäni liittyvät tiettyjen operaatioiden suorittamiseen, ei esim. "Gnomen käynnistymisaika", "Kansion siirtäminen toiselle osiolle" tms., vaikka on niitä vaikeampi vakioidakin.

Lainaus
Minulla kesti 465 GiB:n (~ 500 GB) levyn liittäminen karvan verran alle 25 sekuntia. Kuinka kauan tuolla 150 GB:n levyllä kestää ext3:n määräaikaistarkistus? Kauankohan se kestää 500 GB:n levyllä? Oma tuntumani on että ext3:n keskimääräinen liitosaika on moninkertainen reiserfs:ään verrattuna mikäli tuo määräaikaistarkistus otetaan huomioon (ja mielestäni se pitää huomioida).

Siitä on jo vuosia aikaa. Määräaikaistarkistus on iso/huono juttu, mutta työpöytäkäyttäjille huomattavasti kiltimpi kuin koneen käynnistymisajan esim. tuplaantuminen. Hardyssä tosiaan oletuksena sen voi ohittaa, ja parempiakin keinoja kuten fsck:n suorittaminen sammutettaessa on.

Lainaus
Jos kone toimii esimerkiksi palvelimena niin reiserfs vaikuttaa selvästi paremmalta kuin ext3. Työpöytäasennus on tietysti eri asia.

Palvelimella näin voi olla. ReiserFS:n wikipedia-artikkelissa sanotaan mm. "Some directory operations (including unlink(2)) are not synchronous on ReiserFS, which can result in data corruption with applications relying heavily on file-based locks (such as mail transfer agents qmail[4] and Postfix[5]) if the machine halts before it has synchronized the disk.". Luulen että nämä ovat tuttuja monille ReiserFS-käyttäjille, ja ainakin minulle oli. Se reiserfsck:n --rebuild-tree on IMO paljon pelottavampi vekotin kuin ext3:n normi-fsck.

Edelleen sen mukaan kyseinen rebuild voi korruptoida myös lisää. Käytin sitä kuitenkin korruptioiden sattuessa mukisematta, vaikka silloinkin ohjeissa luki että se on vaarallinen toimenpide - kuitenkin ainoa toimenpide joka toimii ongelmien tullessa kun kone on kaatunut tai sähköt katkenneet. Sitten kun siltä yhdeltä levyltäni oikeasti hävisi tietoja lopulta niin riitti reiserfs. Kyllä tuo korruption / tiedon häviämisen riski tuntuu todellisemmalta kuin ext3:n kanssa. Silti myös harmittaa ext3:n hitaampi toiminta tietyissä toiminnoissa.

(xfs)
Lainaus
Kuinka tuoretta tietoa tämä on? Millä todennäköisyydellä tämä voi pitää paikkaansa vielä nykyään? Entä onko tuo tiedostojärjestelmän vai ainoastaan Linux-toteutuksen ominaisuus?

Lähin referenssi http://pthree.org/2008/04/23/xfs-vs-reiser/ ja Kees Cookin kommentti sekä jlduggerin myötäily power failure -korruptioiden suhteen. Siellä myös viitataan johonkin FAQ:iin jossa asia myönnetään (käytä UPSia..), mutta en nyt löydä sitä. Itse artikkelista löytyy myös tieto että XFS olisi huomattavasti hitaampi kuin ReiserFS. XFS:n Linux-porttauksen kehitys on ilmeisesti kysymysmerkki.

Benchmarkkeja muuten ext2/3/4, reiserfs, reiserfs 4, jfs, xfs, brtfs: http://tservice.net.ru/~s0mbre/old/?section=projects&item=fs_contest2

(jfs)
Lainaus
FUDin sijasta olisi kiva kuulla faktoja.

Jep, JFS on ehdottomasti tarkemman tutustumisen arvoinen, ja minulla on ainoastaan siis muistikuva että olen nähnyt senkin hyvin syin rökitetyn, mutta se muistikuva voi sekoittua XFS-muistikuviin joten tosiaan ei-fudia ei vielä tarjolla.

Lisäys: nyt muistin/löysin että IBM on lopettanut JFS:n kehityksen, joten senkin kanssa on vähän sama juttu että onko kehittäjiä / ylläpitäjiä.

Lainaus
Se määräaikaistarkistus vain on aikamoinen pommi.

Jep, vaikkakin lievennettävissä.

Lainaus
Tämä aivan luonnollista jos lähdetään oletuksesta että ext3 on paras vaihtoehto oletukseksi tällä hetkellä.

Tämä on tosiaan oletus. Hyviä kommentteja on ollut myös joidenkin distroylläpitäjien kommentit, mutta niitä en juuri nyt löydä heti.

Lainaus
Ominaisuuslistaa lukiessa kuola vain valuu, mutta ei voi mitään kun se ei ole lisenssiltään yhteensopiva. Siitä on muuten FUSE-toteutus olemassa eli ZFS-levyjä pystyy tarvittaessa lukemaan ja kirjoittamaan

Katsotaan jos Sun joskus keksisi GPL:tä Solariksensa CDDL:n sijaan, tosin se olisi varmaan sitten v3.

_Jos_ XFS/JFS kehitys on jäissä, ext4:n lisäksi ReiserFS 4 ja ZFS olisivat mahdollisia, mutta eihän ReiserFS 4:nkaan aktiinen kehitystyö lupaavalta näytä, plus on äärimmäisen monimutkainen möhkäle.

lompolo

  • Käyttäjä
  • Viestejä: 852
    • Profiili
Vs: Levy I/O ja tiedosto operaatiot Windows vs Ubuntu
« Vastaus #22 : 14.05.08 - klo:01.02 »
Haastava aihe.

On 3 erilaista journalointitasoa ainakin ext3 tapauksessa. Turvallisin on ensin ja nopein nopein viimeiseksi.
http://en.wikipedia.org/wiki/Ext3

1. Journal
2. Ordered (oletus ubuntussa ext3 kanssa)
3. Writeback (xfs ja jfs käyttävät tätä)

Ext3 osion voi liittää vaikka data=writeback optiolla. Silloin voitetaan nopeutta, mutta virtakatkoksen sattuessa voi hävitä lähiaikoina muuttunutta dataa.

Ainakin joskus reiserfs oli oletuksilla pienille tiedostoille parempi kuin ext3. Tähänkin voidaan vaikuttaa.

mke2fs komennon -T option voi käyttää määrittämään osion käyttötarkoitusta.
 blocksize inode_size ja  inode_ratio ominaisuuksien avulla.

Pienillä tai suurilla tiedostoilla saattaa saada näillä optioilla eron, jonka huomaa. Tuskin kuitenkaan tuollaista huikeaa 160 kertaista.

Oma käyttöni on niin tavallista, että käytössä on ext3 oletusasetuksilla.

Ville Pöntinen

  • Käyttäjä
  • Viestejä: 2078
    • Profiili
Vs: Levy I/O ja tiedosto operaatiot Windows vs Ubuntu
« Vastaus #23 : 14.05.08 - klo:20.18 »
Tähän ketjuun sopiva lainaus tuoreesta Tietokone-lehdestä, kuvateksti s. 63
Lainaus
...Windows-maailman ulkopuolella on koko joukko nykyaikaisia järjestelmiä, kuten Linuxin ext3.

Mippe

  • Käyttäjä
  • Viestejä: 482
    • Profiili
Vs: Levy I/O ja tiedosto operaatiot Windows vs Ubuntu
« Vastaus #24 : 14.05.08 - klo:21.53 »
Lisää testituloksia Vista vs. Ubuntu!

 ;D
AMD Athlon 64 5600+ || ATI Radeon 3650 || 2x 500Gb SATA|| 4Gb RAM || High Definition Audio
Blogi

mgronber

  • Käyttäjä
  • Viestejä: 1458
    • Profiili
Vs: Levy I/O ja tiedostojärjestelmät
« Vastaus #25 : 17.05.08 - klo:19.39 »
Kuitenkin se häviää selvästi...

Oletko nähnyt real-world-benchmarkkeja viime aikoina? Useimmat näkemäni liittyvät tiettyjen operaatioiden suorittamiseen, ei esim. "Gnomen käynnistymisaika", "Kansion siirtäminen toiselle osiolle" tms., vaikka on niitä vaikeampi vakioidakin.

Tuo linkkaamani taitaa olla tuorein näkemäni ja pärjäsihän ext3 siinäkin varsin kohtuullisesti muihin verrattuna. Suurimmat ongelmat olivat vain niillä osa-alueilla jotka ovat tärkeitä digitv-tallennuksia tehtäessä eli suurien tiedostojen käsittelyssä. Erityisesti tiedoston poistaminen on hidas operaatio.

Jos nyt kaksi suurinta ext3:n ongelmaa toteaisin niin ne ovat määräaikaistarkistukset ja suhde jolla levytilaa hyödynnetään. Näitä lukuunottamatta se on mielestäni ihan passeli yleiskäyttöinen tiedostojärjestelmä.

Lainaus
Lainaus
Minulla kesti 465 GiB:n (~ 500 GB) levyn liittäminen karvan verran alle 25 sekuntia. Kuinka kauan tuolla 150 GB:n levyllä kestää ext3:n määräaikaistarkistus? Kauankohan se kestää 500 GB:n levyllä? Oma tuntumani on että ext3:n keskimääräinen liitosaika on moninkertainen reiserfs:ään verrattuna mikäli tuo määräaikaistarkistus otetaan huomioon (ja mielestäni se pitää huomioida).

Siitä on jo vuosia aikaa. Määräaikaistarkistus on iso/huono juttu, mutta työpöytäkäyttäjille huomattavasti kiltimpi kuin koneen käynnistymisajan esim. tuplaantuminen.

Enpä nyt sanoisi noinkaan jos keskimääräisestä liitosajasta sillä tulee suurempi. Tämän arvioimiseksi pitäisi olla jotain tietoa kauanko tuo oikeasti kestää isoilla levyillä.

Lainaus
Hardyssä tosiaan oletuksena sen voi ohittaa, ja parempiakin keinoja kuten fsck:n suorittaminen sammutettaessa on.

Kuinka monta kertaa sen voi ohittaa? Jos sen voi aina ohittaa niin sitä ei välttämättä suoriteta koskaan. Kuinka välttämätöntä sen suorittaminen ylipäätään on? Onko ext3 luonteeltaan jotenkin erilainen kuin muut tiedostojärjestelmät jotta tuolle määräaikaistarkistukselle on enemmän tarvetta vai tuoko se vain lisävarmuutta levyn hajoamisen havaitsemiseen?

Tuo tarkastuksen suorittaminen sammutettaessa kuulostaa minusta hyvältä ja sopii erityisesti desktop-käyttöön. Kannettavissa taas tarkistus ei sovi oikein mihinkään väliin.

Lainaus
Se reiserfsck:n --rebuild-tree on IMO paljon pelottavampi vekotin kuin ext3:n normi-fsck.

Juu, sitä ei parane ajaa ennen kuin kaikki kopioitavissa oleva data on siirretty parempaan talteen.

Lainaus
Edelleen sen mukaan kyseinen rebuild voi korruptoida myös lisää.

Totta. Siksi sitä ei saakaan tehdä ennen kuin kaikki ehjä data on kopioitu talteen. Eri asia sitten jos osiota ei saa lainkaan liitettyä.

Lainaus
(xfs)
Lainaus
Kuinka tuoretta tietoa tämä on? Millä todennäköisyydellä tämä voi pitää paikkaansa vielä nykyään? Entä onko tuo tiedostojärjestelmän vai ainoastaan Linux-toteutuksen ominaisuus?

Lähin referenssi http://pthree.org/2008/04/23/xfs-vs-reiser/ ja Kees Cookin kommentti sekä jlduggerin myötäily power failure -korruptioiden suhteen. Siellä myös viitataan johonkin FAQ:iin jossa asia myönnetään (käytä UPSia..), mutta en nyt löydä sitä.

Tämä oli hyvä tietää. Kiitoksia.

Lainaus
_Jos_ XFS/JFS kehitys on jäissä, ext4:n lisäksi ReiserFS 4 ja ZFS olisivat mahdollisia, mutta eihän ReiserFS 4:nkaan aktiinen kehitystyö lupaavalta näytä, plus on äärimmäisen monimutkainen möhkäle.

Tämän hetken tilanne on kieltämättä varsin synkkä. Tapahtuuko ext4:n yhteydessä jotakin tuolle määräaikaistarkistukselle? Ainakin Wikipedian perusteella minulle jäi käsitys että tarkistus olisi ainakin nopeampi.

Jallu59

  • Käyttäjä
  • Viestejä: 3430
    • Profiili
Vs: Levy I/O ja tiedosto operaatiot Windows vs Ubuntu
« Vastaus #26 : 18.05.08 - klo:15.58 »
Tuo kovalevyn tarkistus bootissa oli jossain Hardyn suunnitteluvaiheessa suunnitteilla siirtää sammutusvaiheeseen, mutta sysstä tai toisesta jaätettiin tuohon boottiin. Senhän verranhan bootissa on syytä tarkistaa, että on millä aloittaa käynnistys. ;D

Ketä asia kiusaa, voi etsiä ratkaisua. Löytyy palikka, joka siirtää tarkistuksen sammutusvaiheeseen. En nyt ehdi hakea sitä, mutta noin vinkiksi.

T:Jallu59
Jari J. Lehtinen, Wanhempi (iki?)tietoteekkari & tietotekniikkakonsultti Turust, P4-HT / 3,0 GHz, Intel945 IGP 226MB & 4GBram & UbuntuStudio 14.04. Toshiba Satellie 50-C, i5 dual-core 2,3GHz, ubuntu-mate 16.04 LTS

qwertyy

  • Käyttäjä
  • Viestejä: 5777
    • Profiili
Vs: Levy I/O ja tiedosto operaatiot Windows vs Ubuntu
« Vastaus #27 : 18.05.08 - klo:17.38 »
Onko fstabissa käytettävällä atime tai noatime parametrilla muuten paljon vaikutusta nopeuteen? En siis oikein ole ymmärtänyt miksi noatime ei ole oletuksena päällä jos sen käyttäminen pitäisi monien jenkkitopicien mukaan nopeuttaa levytoimintaa. Onko tällä eniten yhteyttä indeksointiin, vai?

Eee:llä siis suositellaan tuota noatimen käyttöä, että ssd kestäisi teoriassa pikkuisen pitempään kun kirjoituksia ei pitäisi tulla ihan niin paljon kiintolevylle. Kokeilin huvikseni ps3:lla missä on tuo n.200Mt muistia käytössä ja sehän luonnollisesti swappailee todella helposti + kiintoley mallia kannettava. Ei tullut testattua millään ohjelmalla onko eroa. Perstuntumalta ehkä ihan himpun verran, mutta ei mitään järkyttävää eroa kuitenkaan. Tosin samalla kikkailin vm.swappiness arvon kanssa.

Viisaammilta kommentteja? :)
« Viimeksi muokattu: 18.05.08 - klo:17.40 kirjoittanut qwertyy »

lompolo

  • Käyttäjä
  • Viestejä: 852
    • Profiili
Vs: Levy I/O ja tiedosto operaatiot Windows vs Ubuntu
« Vastaus #28 : 23.06.08 - klo:23.43 »
AdvFS:n lähdekoodi julkaistiin GPL lisenssillä. Seuraava linkki on lähinnä ZFS:n ominaisuuksia kaipaaville.

http://en.wikipedia.org/wiki/AdvFS

Lainaus
Eee:llä siis suositellaan tuota noatimen käyttöä, että ssd kestäisi teoriassa pikkuisen pitempään kun kirjoituksia ei pitäisi tulla ihan niin paljon kiintolevylle.

Tiedoston lukeminen muuttaa sen atimea. Näin jokaisesta lukuoperaatiosta tulee myös kirjoitusoperaatio. Tarkennus kelpaa, mutta toivottavasti idea selviää.