Dotaz: Je ntfs-3g již dostatečně stabilní?

[L_l]

Zdavím, před definitivním "přechodem" bych se chtěl zeptat na možném problémy s čtením a zapisováním dat v souborovém systému NTFS pod linuxovým OS. Rád bych totiž nechal všechna data, která mám na externích HDD, ve formátu NTFS, protože nechci riskovat nějakou nekompatibilitu. NTFS je nejpožívanější v mém okolí, pokud ještě nepočítám FAT32 na flash discích. Když mi disk už ale nebude stačit, koupím nový, větší. Pak ale budu chtít překopírovat data ze staršího disku na nový, takže GNU/Linux bude muset číst z NTFS a poté zapisovat opět do NTFS. Přečte a zapíše se všechno správně? Bude se jednat o větší objem dat, konkrétně nad 1 TB. A existuje nějaký způsob, jak zkontrolovat zda jsou přenesené soubory čitelné i pod Windows? Kromě samotného použití Windows samozřejmě. Díky za reakce.

---

---

Odpovědi

[pushkin]

Naprosto bez problémů používám několik let na externím hdd.
Běžně též používám k servisním účelům (opravám Windows).
Běžně jsem rozšiřoval diskové uložiště Windows Serveru 2003 včetně NTFS pod linuxem.
Ani v jednom z případů jsem nenarazil na problém.
Používáím Arch Linux, tzn. vždy aktuální verzi ntfs-3g.
Mám externí hdd WD s USB3 a kopírování většinou jede něco málo přes 36MiB/s (mně to stačí, pod windows bude asi výkon o něco lepší).
Zdar Max

[pushkin]

Souhlasím. Výkon není tak dobrý jako u nativních souborových systémů, ale stabilita je naprosto bez problémů. Na pár počítačích jsem prováděl i resize NTFS partition (zvětšení i zmenšení) pomocí gparted a ntfs-3g i Windows se s tím srovnaly bez problémů.

[Prcek]

Já jsem teď nedávno měnil velikost NTFS oddílu pomocí KDE partition managera. Nevím proč ale kvůli změně velikosti musel celý oddíl posunout o 0,8 MB doprava, což zabralo pár hodin (přes 100 GB dat na 500GB oddílu).

Ten posun asi způsobil, že Windows 7 odmítal bootovat. Musel jsem vložit instalační DVD a to automaticky chybu opravilo (naštěstí aniž by přepsalo GRUB).

Ale jinak používám ntfs-3g už spoustu let a žádné problémy nemám. Jen ten výkonostní, jak už bylo řečeno.

[lertimir]

Posun počátku způsobí, že Win7 nenabootují. Zřejmě v win zavaděči budou nějaké absolutní adresy. Musím říci, že nejraději používám nástroj, který mi umožní definovat oddíly v hodnotách absolutních čísel sektorů. Pak opravdu mu věřím, co udělá a vím, že za problémy si mohu sám.

[Max]

Klikátka nepoužívám, protože nevím, co dělají a co z toho nakonec vypadne. V tomto případě je možné, že chtělo klikátko automaticky zarovnat na 4K.
Další možností je, že jsi si nějakého nastavení, posunutí apod. nevšiml v onom klikátku.
Zdar Max

[Prcek]

V klikátku posunutí nebylo, jen jsem dal resize a dialog hlásil volné místo před/za oddílem 0 MB. V pending operations se pak objevily 2 opreace: 1) posunutí o 0,8 MB doprava + resize, 2) vytvoření nového oddílu na prázdném místě.

Zřejmě fakt zarovnával. Předpokládám ale, že to samé by se stalo i s jinými nástroji. Všechny tak nějak používají parted a spol. a jenom to GUI se liší.

[lertimir]

Posunout se to s jinými nástroji nemuselo. Patrně si myslel že to zarovná na 1MB hranice. (což je nesmysl to vynucovat.) Osobně mám zkušenost, že gparted z PartedMagick a gparted v Ubuntu a DiskManager jako součást Yast(openSuse) měl jiné návrhy právě pro posunutí začátku. (právě podle nějaké analýzy A vzhledem k tomu, že fakticky pak to klikátko udělá přes příkazy, tak jsem to už začal dělat ručně v případě, že klikátko začne takto nerozumně zarovnávat začátek.

[Peter Golis]

Používaš snapshoty, sparse files alebo enkrypciu na NTFS?

[L_l]

Vůbec nic.

[Peter Golis]

Tak potom môže byť jediný problém keď sa hibernuje Windows s daným USB diskom, disk sa pripojí do iného počítača alebo inej inštancie OS, zapíšu sa naň dáta a následne sa pripojí naspeť do Windows ktoré sa zobudí. Vtedy si pôvodný Windows pamätá stav súborového systému z času uspatia. Linux s touto chybou nemá nič spoločné a ani ju nespôsobuje. Inú chybu som s NTFS na Linuxe nezaznamenal, teda okrem zníženého performance na ktorom pri USB2 nezáleží.

[rastos]

Asi niečo také som zažil a nebolo to pekné (skončilo to prakticky preinštalovaním windowsov). Vyriešil som to skriptom, ktorý sa pustí pri hibernácii a odmountuje všetky NTFS filesystémy.

[lertimir]

Myslím, že v linuxu by to mohlo dopadnout na jejich fs stejně špatně, pokud bych k fs, které jsou otevřené a jejich systém jsem zahibernoval, zkusil přistupovat z jiného systému třeba z live distribuce. hibernace je velmi "nestandardní" stav.

[R]

To by malo byt osetrene - vid man ntfs-3g (parameter remove_hiberfile).

Na zvysenie by mohol pomoct parameter big_writes. Otazka je, preco tam vobec je a nepouziva sa to vzdy...

[Peter Golis]

Čo by malo byť ošetrené, to že Windows na rozdiel od Linuxu nespraví flush na diskovú cache? Tak to určite nebude ošetrené v ntfs-3g. Linux akurát tak zaprotestuje že disk nebol odpojený, a BFU odklikne "pripojiť násilne" keďže máloktorý BFU odpája disky tak ako sa odpájať majú. A potom nedokáže reprodukovať chybu ktorá ho vystrašila.
Neviem prečo mám ten dojem, že som už podobne odborný názor od anonyma podpísaného "R" niekde čítal.

[Ales Hakl]

Osetrene je tim to, ze kdyz ntfs3g pripoji systemovy disk hibernovanych windows pro zapis, tak ty windows se z nej uz pote neprobudi a misto toho budou bootovat z nuly (mam podezreni, ze totez se stane, kdyz pripojite systemovy disk hibernovanych windows k nejakym jinym windows).

[Peter Golis]

Áno, podobne odborný názor od anonyma podpísaného ako "R". Súborový systém NTFS sa používa aj na iné disky ako systémové disky. Vieš si predstaviť ako Ti pomôže to ošetrenie v prípade ktorý som opisoval? Skússi to odsledovať cez USB, veď si písal že si to robil.

[OldFrog {Ondra Nemecek}]

Stabilní to je - léta žádný problém.

Ještě bych se podíval na výkon - při intenzivnějším přístupu na externí NTFS usb-disk mám docela vytížený procesor, vytěžuje to právě ntfs-3g. S jiným souborovým systémem jsem to ale neporovnával.

[L_l]

Ptám se právě proto, jelikož když jsem v Ubuntu kopíroval soubor z ext4 na NTFS, všechno proběhlo regulérně. Později, když startoval Windows 7, soubor se nedal přečíst, i když tam byl. Ubuntu nemělo problém. Nechal jsem jej překotrolovat windowsáckým ch.diskem. Našel chyby, které opravil. Jeho "oprava" ale způsobila to, že nenčitelný soubor zneviditelnil. Ubuntu opět dovedlo číst i Windowsem odstavený soubor...Při opakování přesunu (totožný sobor, přesun z extt4 na NTFS) už pak i Windows soubor normálně přečetl a chyby již nehlásil. Nechci, aby nastala situace, kdy si budu kopírovat soubory z disku na disk, a za několik let zjístím, že pod Windows vůbec nic nepřečtu, nezkopíruji, nepřepíši.

[rws]

A nebyly ty Windows nahodou hybernovane? To samozrejme nesmis, protoze Windows zahybernuje aktualni stav (ne celeho disku, ale zrejme nektery diskovy data) a pak je zmatenej, kdyz je na disku neco jineho. To same se mi povedlo taky - ulozil jsem na NTFS data, kdyz byly windows hybernovane a pak byl bordel na disku, kdyz windows znova nabehly.

[L_l]

Windows hybernované určitě nebyly. I samotný disk byl před tím defragmentován. A jak jsem už psal trochu dříve, později jsem celý proces ještě několikrát opakoval se stejným souborem, ale později i s jinými. Všechno bylo OK. Ta ojedinělá chyba mě ale štve, protože neznám její příčinu. A nejvíce alarmující je skutečnost, že v Ubuntu byl chybný soubor v pořádku, ale Windows. A dejme tomu, kdybych Windows nespustil třeba několik let, pak bych též několik let žil v domnění, že jsou zálohované soubory v NTFS v pořádku. Zde by byl vhodný nějaký program pro kontrolu hash chyb, nemyslíte?

[OldFrog {Ondra Nemecek}]

Střídání Windows XP a linuxu - u mě vždy bez problému.

Nemohlo jít v popisovaném případě o nějaké specielní features Windows 7 - práva, komprese nebo něco takového - které linux nepodporuje a Windows jo?

[L_l]

Jestli odpoví někdo jiný... Nejsem geek, ale pořádný BFU, takže mi není známo, jestli má Windows 7 nějaké komprese. Znal jsem člověka, který si občas nechal komprimovat soubory. Windows mu zkomprimoval ty soubory, které nepoužíval. Ušetřil tak nějaké místo na HDD. Já ale kompresi neprovádím. Na disku je místa dost a nikdy nevím, co kdy budu potřebovat použít. Ještě mě napadají vadné sektory, ale SMART je OK, ch.disk také OK. Abych měl jistotu, chtělo by to tip na nějaký linuxový program, který udělá kontrolu na hash chyby, který je schopen soubory zkontrolovat i na rozdílných souborových systémech a následně je porovnat. Pak by tady byla jistota, že přenos proběhl skutečně normálně. Když tak někdo dejte nějaký tip, existuje-li nějaká taková aplikace.

[Z]

md5sum soubor utilitka je portovana i pod win

[L_l]

Díky. Mě al enezajímá, jestli to umí dělat pod Win, jde spíš o to, aby nějaká ta utilitka, KTERÁ BUDE POD PRACOVAT V LINUXU, dovede zkontrolovat soubor v ext4 a následně i v NTFS, aby srovnala, jestli jsou oba soubory totožné. O to jde.

[L_l]

Oprava: "KTERÁ BUDE PRACOVAT V LINUXU".

[Peter Golis]

Nástroj md5sum funguje aj v OS Linux, a mnohých ďalších. Ale, na súbory nad 2G by som odporučil niečo iné. Napríklad sha*sum.

[L_l]

Díky za tip.

[Ales Hakl]

Muzu se zeptat na duvod takoveho doporuceni? 2GB je 2^31 coz je vyrazne mene nez 2^61 byte coz je jak limit velikosti zpravy pro MD5 tak pocet ruznych zprav (deleno osmi, protoze byte a ne bitu) ktere jsou potreba pro nahodnou kolizi vlivem narozeninoveho paradoxu u hashovaci funkce s 128b vystupem. Padding u SHA-1 a SHA-2 je uplne stejny jako u MD5, takze limit na delku zpravy je stale 2^61 byte.

Naopak pro porovnani velkych souboru za ucelem overeni spolehlivosti prenosu/ulozeni je vhodne pouzit nejakou funkci, ktera je rychla bez ohledu na kryptografickou bezpecnost, nabizi se treba MD4 (coz do roku 2008 pouzival rsync, nyni pouziva MD5 spise s politickych duvodu), nebo CRC-128.

[Pavel Stárek]

No a hlavně, jestli se nemýlím, tak md5sum umí dát stejný heš na různá data (nebo takový nějaký problém s tím byl). Asi tedy je lepší sha1sum.

[vandrovnik]

Stejný hash na různá data teoreticky může vrátit každý hash, u sha-1 je to ale méně pravděpodobné.

[jekub]

http://www.youtube.com/watch?v=-BLo6-8_gXQ

[L_l]

Nemám smysl pro humor.