milyen fajlrendszerre mentsem az adatokat

Linux-kezdő

udv mindenkinek,
bar mar sok eve hasznalok linuxot, ido hianyaban vhogy sosem sikerult meg a kov. problema vegere jarnom, de most h. ismet uj vinyot veszek, ujra aktualis a nagy kerdes, milyen fajlrendszert rakjak ra?

a kriteriumok:
-csak adat vinyo (zene film), terveim szerint 1 nagy particio lenne, bar ntom van-e ennek hatranya (funkcionalisan nekem tutti csak jo)
- windoz (win2k, xp) es linux (2.6.uj kernelekkel) alatt is mennie kell /iras-olvasas/ 1000%-osan.

eddig erre egyetlenegy bevalt fajlrendszert ismerek, a fat32-ot.
egyeb (bevalt) javaslatok?

regebben (1-2 eve) kiserleteztem ilyen fantasztikus e2fs windows driverekkel, szepek is voltak, meg jok is, de 10 percnel soha nem tartott tovabb hardresetbe kuldeni a gepet (50 GB mp3 winampban megnyitasa), szoval kicsit elkeseredtem, hgoy erre a problemara nincs jobb megoldas, mint a fat32:(

elroe is koszi a segitseget:

kukocs

  • 1593 megtekintés

( pomm v | 2007. 05. 23., sze – 12:21 )

A legjobb megoldás, ha törölöd a win-t és akkor jó az ext3 vagy xfs, stb... :)
Komolyra fordítva a szót, az ntfs-3g már nagyon jól kezeli az ntfs-t, lehet jobb választás, mint a fat...
üdv: pomm

( pgergely | 2007. 05. 23., sze – 13:18 )

Hát én fat32-ben nem nagyon bíznék, ha nagy partíciókról van szó. Vannak komoly korlátai, maradjunk annyiban. Én is inkább ntfs-re voksolnék, linux alá meg behegeszteni ntfs-3g-t.

-- pgergely --

a fat32 nyilvan full elavult meg minden, de en meg arra mondom azt, hogy mukodik, mig az ext2fs reader hardresetre csapta a gepem nem 1x, hanem konstans modon:(.

az ntfs-3g 'eltunt a particio' sem hangzik vmi jol,
tenyleg se xfs-hez, reiserfs-hez, mittomen mihez nincs windowsos driver? mi ennek az oka??
M$ meg azert is licencet ker, h vki fs drivert irjon a windowsba?? azt hinnem ingye le lehet szippantani az sdk-kat...

asszem marad a fat32 - mert bevalt(tm)

( jsaak | 2007. 05. 23., sze – 16:02 )

fat32 a multe, igaz mindenki kezeli, de elvesznek rola az adatok
ntfs-3g ugyan nagyjabol mukodik, de nem az igazi
ugyhogy marad az ext-3

ekezetek nelkul: http://www.fs-driver.org/
nekem stabil volt

ekezetekkel: http://ext2fsd.sourceforge.net/
ez egy kicsit fapados, de nem volt meg bajom vele, en ezt hasznalom az utf8 miatt

( BaT | 2007. 05. 23., sze – 16:08 )

Nekem is ilyen problémám volt 1 éve. Először volt fat32 kompatibilitás miatt, de a 4G-s fileméretkorlát miatt átraktam az egészet ext2-re. Winen ext2ifs volt, ami marha jól szuperált. Leszámítva azt az apró hibáját, hogy egy több gigás file kitömörítésekor hardreset volt. Pedíg akkor már javították ezt a bugot elvileg. :) Végül áttoltam a partíciót ntfs-re. Akkor gugli ntfs-3g-ről nem sokat tudott, szóval captive ntfs-t használtam. Lassú volt, de mivel a win driverét használta, ezért 100%, hogy nem rontja el a partíciót. Aztán itt a hupon olvastam az ntfs-3g-ről, és azóta az van. (Ez az FC6 kiadása idelyén történt.) És azóta nincsenek problémáim az adatpartíció írása/olvasása körül linuxon és winen. :)

Amúgy ext2ifst sokáig úgy használtam, hogy nem volt win mellett működő linux, így nem volt probléma, hogy nem kezeli az utf8-as ékezeteket. (De winen létre lehetett hozni ékezetes fileokat, azokat kezeli is rendesen, de az utf16-ban van, amit linux nem kezel...)

A FAT32 jó, bevállt. Sose veszett el adatom róla, Linux-on sincs soha gond vele.

NTFS-3G nálam néha, ha oda töltöttem valamit torrentről (mikozben fel is ment), a 3 GHZ-es proc stabilan 40%-ra terhelte. Ha valamit mint root kicsomagoltam NTFS-be akkor sehogy se lehetett törölni (root+force se), csak XP scandisk után, mert még XPSP2-ről se lehetett törölni. :(

Szerintem oszd fel a HDD-t és használj FAT32-őt és legyen 1 NTFS is, ha netán valami 4GB+ fájl jönne. :)

akkor leteszek arrol a perverziomrol, hogy egy fajlrendszer akkor tamogatott, ha van hozza jol mukodo fsck is, mivel ugy latszik a tobbsegnek nincsnek ilyen "magas" igenyei

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

( Mik v | 2007. 05. 24., cs – 07:53 )

Többen írják h. FAT32-vel több gondjuk volt. Én kb. 3 éve dolgozom rendszeresen egy SATA HDD-n lévő 90 GB-os FAT32 partícióra, nem volt vele gondom.

Mik

A FAT előnye, hogy egy win98 boot flopyval is el lehet érni a tartalmát.
Oda kell viszont figyelni a Cluster méretre.
Megnézted már, hogy mekkora Cluster méretet használsz? Ekkora méretnél (90GB) az elvi minimum 16kb. Ez azt jelenti, hogy minden egyes fájl 16kb egész számú többszörösének megfelelő helyet foglal a lemezen. Egy egy bájtos fájl 16kB-ot, egy 16kB+1 bájtos fájl 32kB-ot. Ez a helykihasználás szempontjából akkor fontos, ha apró fájlokat is tartasz a lemezen. Viszont ha az elvi legkissebb Cluster méretet választjuk, akkor nagyon könnyen belefuthatunk abba, hogy a maximális fájlméretünk lesz túl kicsi, (2 vagy 4 GB).

Van még oyan gép, amiben van floppy meghajtó? :)
Live CD-vel el lehet érni LVM-et is, szóval LVM + XFS (ha nem fagy a gép, szabályosan áll le, stb.), vagy ReiserFS (ha ez nem teljesül) a mentésre használt részen. Az LVM előnye, hogy a logikai kötetet lehet bővíteni újabb és újabb merevlemezekkel. Nálam így van összekötve 2 külső HDD.
--
hup.user.js

A Fat nagy hátránya, hogy nem tudja magáról, hogy beteg. Ha vmi összekuszálódott rajta és továbbra is használod, akkor nagy-nagy szívás lesz a vége.
A naplózott fájlrendszerek észreveszik, ha nem teljesen rendben lettek leállítva és visszavonják az utolsó tranzakciót (végre sem hajtják? mindegy, nem lényeges) vagy futtatnak egy fsck-t (ext3), szóval visszaállítják az egészséges állapotot.

osszefoglalva: azt kell hogy mondjam, a fat akarmekkora fos, nekem sem volt meg megmagyarazhatatlan adatvesztesem rajta. szoval fat32 @ 320 GB .

de tenyleg rohadtul nem ertem, miert nem lehet barmelyik atomszupifolyamtosantovabfejlesztodo xfs/reiserfs/hfs/oaegjaoFS-hez egy rohdat mukodo vindozos drivert irni

koszi a sok-sok infot a tapasztalatokrol!

osszefoglalva: azt kell hogy mondjam, a fat akarmekkora fos, nekem sem volt meg megmagyarazhatatlan adatvesztesem rajta. szoval fat32 @ 320 GB .

de tenyleg rohadtul nem ertem, miert nem lehet barmelyik atomszupifolyamtosantovabfejlesztodo xfs/reiserfs/hfs/oaegjaoFS-hez egy rohdat mukodo vindozos drivert irni

Sziasztok,

Próbáltatok win alól fat32 partíciót létrehozni/megformázni EGYBEN ekkora méretben? Ha jól emlékszem 8GB fölötti partíciót nem enged. Persze ha linux alatt írod a partíciós táblát, és a win észreveszi, hogy ott van egy fat32 cimkéjű formázatlan partíció, hajlandó leformázni (így használtam 100GB-os partíciót), de...
Ha mindkét rendszer alatt erőteljesen írod, és használsz ékezetes fájlneveket, sikerülhet linux alatt olyan fájlt írnod, amit a win nem tud kezelni, sőt közli hogy sz@r a fájlrendszer, hosszas nyögés után sem sikerül megjavítania, és (nálam háromszor ugyanígy csinálta) ekkor kerül olyan állapotba, hogy szinte tuti az adatvesztés.
Ja, és ezt csak a nagy partíción csinálta, mert a két rendszer közti másolásra a mai napig egy 8GB-os partíciót használok.
Ja, és a nagy fájlok... Ne rakj rá DVD image-et :-)

FAT32-ből a Windows telepítő max 32(? - 40-et már nem) GB-osat enged, a mkdosfs meg 100 GB-ost is csinál (kipróbáltam, a Windows is látja, de használni nem mertem); a 8 GB határ urban legend:
http://en.wikipedia.org/wiki/File_Allocation_Table#FAT32

szerk: látom már lejjebb írták bocs.

FAT nem = FAT32-vel. A FAT az tényleg nem lehet nagy, de FAT32 az igen és nincs hibaüzenet (nálam).

http://en.wikipedia.org/wiki/File_Allocation_Table#FAT32

Windows ME supports the FAT32 file system without any limits.

A létrehozásra használjatok Partition Magic-et vagy Paragon HDD Managert és akkor Windows-on se lehet hiba.

Nekem NTFS-3G-vel vannak problémáim az ékezetekkel meg a szegletes zárojelt tartalmazó fájlnevekkel. FAT32-őn ilyen nincs.

Mindenképp jobb Linuxon a Ext3, de következő megoldás a dologra (4GB+) azon a partición ahol a Linux rendszered van kell hogy legyen +5-10 GB hely és oda menthető.

Szerintem itt mindenki a FAT32-ről beszélt és igenis vannak fájl méret korlátok, amelyek összefüggenek a beállított Cluster mérettel illetve azzal, hogy hány foglaltsági egység (Cluster) tartozhat egy fájloz. Tapasztalatból tudom, nem azért mert olvastam valahol.

Amikor FAT-ot írtam a FAT32-re gondoltam, bocs... FAT12-ővel nincsenek tapasztalataim. :D

Fájl-méret korlát van, de particio-mért lehet nagy, bár nincs extrém nagy HDD-m, de 160 GB az biztosan (ilyenem van csak).

Én is használok NTFS-t, de amint írtam voltak gondok Linuxon.

"Windows 2000 and Windows XP can read and write to FAT32 filesystems of any size, but the format program on these platforms can only create FAT32 filesystems up to 32 GiB."
"The maximum possible size for a file on a FAT32 volume is 4 GiB minus 1 Byte."

forrás:
en.wikipedia.org/wiki/File_Allocation_Table

Nem. :) Itthon csak frissíteni szoktam Ubuntut, kb. 1 óra alatt lejönnek a csomagok. Cégbe szoktam 1 CD-s verziókat telepíteni, ami extra kell az már netről jön. Gigabitnél minek töltögessek Linux DVD isokat? :) De majd ha ilyenre lesz szükségem, akkor van ext3 ahol elfér egy DVD iso :)

Mik

a folos helyfoglalas csak egy dolog, hogy mennyi memoriat pazarolsz el az sem semmi ekkora meretnel mar, mivel a fat32-es filerendszerek leiro tablajat bootkor 1az1ben behuzzak a memoriaba, hogy ne kelljen a fejnek allandoan ugralnia a disk/particio legeleje, es az adat kozott. Itt van a ugyanis a tabla, elmes modon legelol a mester peldany, es KOZVETLENUL mogotte a masodpeldany (tehat egy esetleges fizikai hibanal pl szinte biztos hogy mind2 megserul :)). Az ntfs ezzel ellentetben az MFT egyik peldanyat a disk/particio elejen, a masikat a disk/particio kozepen tarolja, nem huzza be az egesz tablat a memoriaba mint a fat (ezert van hogy sok esetben az ntfs kicsivel lassabb is mint a fat).

Hogy pontosan mennyi ramot nyul le a fat egyebkent az fugg a particio meretetol es a clustermerettol, igy fejbol nem tudom mar megmondani (nem talaltam meg a tablazatot amiben mindig megnezem), de vagy fele annyi MB-al, vagy ugyanannyival kell szamolni mint amennyi GB a particio merete, tehat 90GB-os particional akar 90 mega ramod is eluszhat ugy alapbol.