Adatot vesztettem fájlrendszer hiba miatt **Linuxon** a következőkről:

Fájlrendszer, NAS, storage

ext2
3% (19 szavazat)
ext3
9% (60 szavazat)
ext4
2% (11 szavazat)
többféle ext
1% (6 szavazat)
reiserfs
7% (46 szavazat)
JFS
1% (4 szavazat)
XFS
4% (29 szavazat)
többféle fájlrendszer/egyéb (leírom)
3% (19 szavazat)
nem vesztettem még adatot
66% (449 szavazat)
nem használok linuxot
5% (34 szavazat)
Összes szavazat: 677

( trey | 2010. 07. 23., p – 10:16 )

Emlékeim szerint soha, semmilyen operációs rendszeren sem vesztettem adatot fájlrendszerhiba miatt. Hardverhiba miatt már volt, hogy backup-ból vissza kellett állnom, de fájlrendszer hibára nem emlékszem.

Ext2/Ext3-at és ReiserFS-t használók sok-sok éve.

--
trey @ gépház

Anno egy sokak által piszkált és kókányolt NW-t örököltem meg, már down-olni se lehetett rendesen. Mielőtt lecseréltük muszájból többször kinyomtam a szemét, semmi baja nem lett.
Nem mondom hogy nálad nem így történt, de én képtelen vagyok elhinni, vakon szeretem az NW-t :D

______________________
echo crash > /dev/kmem

Lehet véletlen pont a "for i in `find / -type f`; do mv ${i} /; done && find / -type d | xargs rm -rf" sort pötyögte be, ahogy lépkedett! Szóval ez még nem bizonyíték fájlrendszer hibára!

Szerk.: ja bocs, most olvasom, hogy Netware volt, a fenti lehetőséget akkor kizárhatjuk. Tényleg fájlrendszer hiba lehetett.

nekem nemreg szaltak elaz adataim, talan az IDE kabel nem erintkezett egy pilanatra, talan vmi aramingadozas volt, nmetudom, azthittem uj hdd-t kell vennem, de nem volt semminek semmi baja, azota is hasznalom a gepet, minden mukodik.
sosem tudom mar meg h mi volt a baj, de a HW azota is jo, egy ilyen utan egy naplozo filerendszernek azert talan illene helyreallnia

(amugy ezt a rendszert kb 3 evig hasznaltam gond nelkul... (debian etch))

A hagyományos MOLEX (AT) tápkábel -pláne Y-elosztóval- imád kontakthibás lenni, ami észrevétlenül odab'sz akár egy RAID6 tömbön elfekvő fájlrendszert is úgy, hogy a RAID nem esik szét, talán még a dmesg -ben sem látsz semmit. Aztán egy kis mozgatás után lehet, hogy fél évig se jön elő újra a hiba.

Ennek a titoknak a nyittya az átkozott writeback cache a winyón.

Ha a winyót a bekapcsolt writeback cache kiírása közben éri a tápkiesés akkor adatvesztés lép fel, amiről a kernel talán tudomást sem szerez, csak épp attól a pillanattól kezdve a fájlrendszer lábon van lőve. Ez a kiesés sajnos könnyen hazavágja a RAID6 -ban lévő adatokat is, mivel a kernel nem tudja, hogy nem sikerult az írás (a writeback cache -be sikerült), olvasáskor pedig nem (feltétlenül) számol paritást, hiszen nem tudja, hogy baj történt, pedig a metaadatok helyén szemét van, amitől bármilyen fájlrendszer fejreáll.

Az utóbbi pár évben (a barkács-szerverekben) több adatvesztést láttam a 200ft -os Y kábel hibája miatt mint winyóhiba miatt.

A kontakthibát SMART -al lehet elkapni, figyelni kell a SMART 4(Start_Stop_Count), 12(Power_Cycle_Count) értékeket. Vagy barriers, barriers, barriers..

( nanto | 2010. 07. 23., p – 11:05 )

egyeb, leirom hozzaszolasban: adatot Linuxos pasrticiorol még csak akkor vesztettem, amikor a BIOS nem bootolta mar be a vinyot, mount egy ezer sebbol verzo vinyon is mukodott _nekem_ ext3-on (ext4-en nem, de az friss telepites volt, nothing to lose)

edit: atnyomtam a szavazatot ext4-re, bad sectoros vinyo ide vagy oda, akkor is mount errora futott egy felkeszen telepitett Fedora

<-----------
Arra van Buda!

Archlinux user with KDE!
Gentoo-s daily routine: reggeli, ebuild, vacsora

per def az, volt rajta egy felkesz OS, ido ujra beszerezni az amarok2.2.0.fc11.x86_64.rpm-et es tarsait foleg kicsomagolva ;) Nem fajlrendszer hibaja miatti adatvesztes esetleg, de en annak szamitom, mert bad sectoros vinyokon szepen elfutogatott nekem az ext3

<-----------
Arra van Buda!

Archlinux user with KDE!
Gentoo-s daily routine: reggeli, ebuild, vacsora

( zdesigner | 2010. 07. 23., p – 10:30 )

ReiserFS + áramszünet = adatvesztés. Csak egyszer történt meg, pedig már többször volt Reiserrel áramszünet. Mindegy, azóta van szünetmentesem és csak ext3 meg ext4 partícióim.

--
#FreedomFlotilla

( tomaza | 2010. 07. 23., p – 10:32 )

aki azt írja vesztett, szerintem többen örülnének ha részleteznék

( bra | 2010. 07. 23., p – 10:37 )

ext2/ext4. Előbbivel odáig jutottunk, hogy az egész fájlrendszer ment a levesbe. Máig sem bírom elképzelni, hogy lehetett a default async mountot alkalmazó Linuxot bármilyen gépre feltenni.
Azt hiszem valamikor azután kezdtem el ismerkedni a FreeBSD-vel. :)

Utóbbi pedig: openoffice.org-ban nyomtam egy CTRL-S-t, végigment a bitkígyó, ablakot váltottam, beírtam valamit a böngésző címsorába, majd csontra fagyott a gép.
Újraindítás után a lementett doksi 0 bájtos volt. Nem voltam boldog, dehát Ubuntu-megérdemled. Egyébként Ubuntu 10.04 Likvid Likud (akkori) default settings release, legújabb kiadás.
Biztos hardverhiba, sokan elmondták már itt, hogy azt jól kell választani (közben jött pár upgrade és azóta nem volt egy fagyás sem, tuti ettől függetlenül megjavult a vas).

( waiter | 2010. 07. 23., p – 10:42 )

Érdekesebb lenne az, hogy az adott fájlrendszert használók mekkora hányada vesztett már adatot. Így szerintem kb. azt fogod visszakapni, hogy melyek a legnépszerűbb fájlrendszerek.

- waiter -

( Pontscho | 2010. 07. 23., p – 11:01 )

Reiserrel meg ro-ra mountolt fs-rol is minden aramszunet eseten vesztettem mar adatot. Ext3-rol meg nem.

A kedvencem viszont az xfs volt. Egy ekezetes filenev krealas utan soha tobbet nem lehetett azt a particiot felcsatoni. Nem mai tortenet, de tanulsagos. :)

---
pontscho / fresh!mindworkz

Nálam default, úgy 6 éve minden gépen az xfs. Akkor váltottam rá, amikor 6 éve a régi munkahelyemen többször volt vihar miatt áramkimaradás úgy 2 héten belül, és egyedül az xfs-ek élték túl :-). Nyilván nem releváns, pár gépről van szó, most itthon asztalin és laptopon is az van, de nekem bevált.

( asch v | 2010. 07. 23., p – 11:36 )

nem vesztettem még adatot - legalábbis fájlrendszer hiba miatt nem.

( cannibal | 2010. 07. 23., p – 11:46 )

ext2, ext3, reiserfs, aztán linux, azóta csak mysql szinten történik adatvesztés

+1 Az áramszünet után fellépő fájlrendszerhiba pedig gyakori minden típusú fájlrendszernél a winyók writeback cache-e miatt.

Az LVM fő bűne szerintem, hogy a barriers -t csak 2.6.29 óta engedi át (szóló winyós VG -nél), miközben az LVM évek óta alap rootfs -re a nagy disztribeknél. Emiatt az áramszünet a legtöbb (otthoni) linux felhasználónak orosz rulett.

Valoszinuleg ezzel az emberek nagy resze nincs tisztaban (writeback cache, mount opciok) es csodalkoznak, hogy ha elmegy az aram akkor nincs meg az adatuk amit 2 masodperce mentettek le. De ha meg ultrabiztonsagos beallitasokkal mountolnak egy kotetet akkor meg siras van, hogy lassu, gagyi a fajlrendszer.

Jo latni, hogy van aki olvas is. Nem arrol van szo, hogy nincs szar a palacsintaban, en is vesztettem mar el raid tombrol adatot, mert az EXT-4 eppen rossz labbal ebredt. Amikor megmutattam az eredmenyt meg a hibauzenetet Ted Ts'o nem tudott ra magyarazatot adni. Ez fajlrendszer hiba. Az, hogy rossz mount opciokkal csatolsz egy kotetet, meg elfelejted bekapcsolni a szunetmentes tapot, az nem.

( Hiena v | 2010. 07. 23., p – 12:17 )

ext3, ext4 mindkettővel 4 alkalom.
Adat nem veszett mert volt backup.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( Huncraft v | 2010. 07. 23., p – 12:31 )

ext2, ext3.. Nem is egyszer.. Azóta kerülöm az ext* FS-eket ( az egyik kedvencem, amikor bármiféle HW failure nélkül úgy csontrafagyott a rendszer, hogy a reboot után az fsck totál szétvágta az egész FS-t, onnantól meg a rendszer mint olyan csak egy random bithalmaz volt, helyenként file-okban tárolva ). Részemről jelenleg az XFS a preferred egy szünetmentessel megtámogatva.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( Chain-Q v | 2010. 07. 23., p – 12:49 )

Nekem rendszeresen volt olyanom, még szépemlékű rendszergazda koromban, hogy áramszünet után (megdöglöttek a szünetmentesek is) minden szerver gond nélkül felállt (OS/2, Netware, Win2000) kivéve a Linuxok. Azokat rendszeresen maszírozni kellett kicsit (kézzel fsck). Az egyik ilyen esetnél volt is, hogy talán még ext2 úgy megsérült, hogy csak formattal és backupból visszaállítással lehetett helyrerakni. Sok adat nem veszett, de azért nem volt kellemes.

Egyszer borult meg soft RAID1 tömböm is Linux alatt, összevissza állt neki szinkronizálni a lemezeket, eredmény két halott filesystem (ext3) és csak részlegesen lementhető adatok. Lehet, hogy hardverbug okozta, de annyira nem is lényeg, elég csúnyán megdöglött, pedig a HDD-k jók voltak alatta. Szintén backupból restore volt a vége.

A szerverek egyébként egymásra mentették az adatokat éjszakánként, a Linux backupjai az OS/2-n és a Netware-en voltak, és csak bármimás -> Linux irányban került sor helyreállításra, kb. háromszor a 4 év alatt. A trollok dolgát megkönnyítendő, természetesen nem értek hozzá, felesleges erre felhívni a figyelmet. :P

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( valaki123 | 2010. 07. 23., p – 12:58 )

xfs-re szavaztam, de nem kizárólag az volt a hibás.

Vicces kolléga kilépése előtt telepített egy rendszert. Mivel sikerült khmmm "belépő szintű szervert" vetetnie a céggel - tehát nem a szokásos legót a hardverboltból - ezért úgy gondolta a mentés már nem szükséges. Erről sikerült is levelet küldenie, csak sajnos a sok kilépés miatt nem sikerült a többieknek feldogozni ezt az információt.
Az xfs alatt különböző szintű szoftveres raid-ek figyeltek, illetve lvm, mint azt sikerült utólag kideríteni. Ja persze doksi nem volt. A probléma ott kezdődött, hogy felmerült a gép újraindításának gondolata. Kb itt volt vége is a történetnek. Többet nem lehetett az adatokhoz hozzájutni.
Találós kérdés: mikor történhet ilyen katasztrófális leállás: persze, hogy szilveszterkor!

Nem tudom, hogy ebben mennyi volt az xfs hiba, viszont a vele kapcsolatos lényegesen kevesebb meglévő tapasztalat rontotta az esélyeket.

( padawan | 2010. 07. 23., p – 14:31 )

Vesztettem mar, de csak nem-kritikusakat. Amugy meg volt backup (eredeti CD formajaban) :)

( Lacyc3 v | 2010. 07. 23., p – 16:39 )

ext3

Valahol a 2.6.30-as kernel környékén amikor már nem volt akkora újdonság a kexec gondoltam kipróbálom. Minden folyamatot szépen leállítottam, újracsatoltam a / és a /boot -ot ro-ként, single-user módba léptem és hajrá. A művelet után egy kernel pánik és egy elszállt ext3-as kötet volt a jutalmam. Azóta újra próbálkoztam és sikerült adatvesztés és pánik nélkül megúszni a dolgot.

off: Összes szavazat: 404 :) :/off

( saabi v | 2010. 07. 23., p – 19:39 )

Adatot nem szokás elveszteni, nem azért van az.
Meghibásodásból eredő állás, plusz munka már elképzelhető, de adatvesztés soha! Loser akinek ez összejön. :-P
(én is voltam már ilyen loser)

Ave, Saabi.

én úgy értelmeztem a kérdést hogy a fájlrendszer hibázott-e és veszett-e el adat, azt már a szavazás szempontjából lényegtelennek tartottam hogy ami elveszett azt meg is lehet keresni
(gondolom te is arra gondolsz a backup és hasonló fiókokba bújik általában)

mert így láttam értelmét a szavazásnak, ezért döntöttem e mellett az önkényes mellett, de ahogy látom megint én értelmezem rosszul

(tehát nem pl a rendszergazda hibájából hanem a fájlrendszeréből, és az "elveszett de meglett" értelmes magyar összefüggést felhaszálva próbálkoztam)

( hrgy84 | 2010. 07. 24., szo – 01:32 )

Tobbszor meselt sztori: ext3 vs VMware Server (1.x), splitted diskekkel. Tobbszaz giga adat, tobbheti munka veszett oda. Persze, mert a fonok soher volt, es nem volt Raid a rendszer alatt.
-- 


Ki oda vagyik, hol szall a galamb elszalasztja a kincset itt alant.

( hnsz2002 v | 2010. 07. 24., szo – 12:42 )

Tegnap, de nem teljesen fájlrendszer hiba miatt.
Az isteni szerencse az volt, hogy csütörtök este upgradeltem 11.3-ra, előtte toltam egy backupot, a rootról is.
A dolog úgy történt, hogy tegnap reggel s2disk-be ment a gép, aztán lekapcsoltam az elosztót, mint mindig. Délután hazamentem, gép bekapcs... Hmm-hmm, login. Hát mondom reggel biztos hamarabb lenyomtam az elosztót, minthogy befejezte volna a hibernálás (volt már ilyen). Na nembaj, nem volt megnyitva semmi olyan, login. Este felrakott pár updatet még, gondoltam reboot. Újra is indult... ÉÉÉS, visszatöltötte a hibernálás állapotot. Na itt aztán minden megfeküdt, ext3 és ext4 is. Össze-vissza belefirkált mindenhova, ebbe bármilyen FS beledöglött volna. Na még egy reboot, reménykedtem, hogy elindul. Hát nem tette... Run fsck manually, give root password for login. Küzdött vele az fsck nagyon sokat, nem tudom hány ezer hibát javított összesen. Utána elindult épp a rendszer, csak hát nagyon sok fájl sérült volt.
Úgyhogy éjjel visszamászott a backup, most reggel meg toltam rá megint egy upgrade-et, így vagyok most :). Szerencsére semmi olyat nem csináltam tegnap, amit 5 perc alatt ne lehetett volna pótolni.

Hogy hogy történhetett ez? Hát úgy, hogy 3 hdd van, mdadm raid5-be a boot-ot kivéve minden. Namost a délutáni induláskor sdc az így nem volt a fasorba se, nem tudom miért, lehet már kezdi megunni a dolgot. Ez még ugye nem lett volna gond, viszont a swapből sdb is kiesett, mint spare szerepelt. A többi tömb elindult 2 taggal, én meg észre se vettem, hogy hiányzik az egyik hdd... 1 hddvel ugye már nem megy a raid5, nem tudta visszatölteni a hibernálás állapotot. Aztán az esti újraindításkor már visszatért sdc, swaphoz is megvolt a szükséges 2 tag, startolta a tömböt, a kernel meg megtalálta, és visszatöltötte ami ott volt... Hurrá :)
--
Discover It - Have a lot of fun!

( turul16 v | 2010. 07. 24., szo – 19:16 )

Menyire garantalt/garantalhato, hogy az iras olyan sorrendbe megy tenylegesen vegbe, mint ahogy azt az FS szeretne ?
Akkar vinyo is atrendezheti a tenyleges irasi sorrendet AFAIK.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( Lightning | 2010. 07. 25., v – 16:39 )

Sokáig ext3 fájlrendszereket használtam és csak idén tértem át fokozatosan ext4-re. Többet 3-ról konvertáltam át 4-re. Áramszünetek előfordulnak (van, hogy zsinorban), de emiatt adatott még nem vesztettem. Remélem, ez nem fog változni a jövőben sem.

Viszont olyat sikerült csinálnom, hogy a partíciók és a fájlrendszerek egy lemezen eltérő méretűek voltak. Így ha arra írtam amelyik átfedte a másikat szépen beírkált a másik fájlrendszeren levő fájlokba. Csodálkoztam is, hogy mégis mért van ennyi csonka fájlom, aminek hiányzik a ~fele? :)

( cannibal | 2010. 07. 25., v – 16:52 )

preliminary report:

- a szavazók 66%-a valódi noob, aki csak alkalmi bugrókázásra használja a linuzot, hiszen igazi real world use-nál előbb-utóbb elkerülhetetlen az adatvesztés

- mint ahogy a 31%-uk már tapasztalta is

- ebből 2% nem jutott el a kétségbeesésben addig, hogy talán ki kéne dobni az ubuntut, ehelyett a létező - ám linuxba be nem került - filerendszerek ötleteinek összecsórásával létrehozott ext4-be fektették reményeiket, majd természetesen ott is adatvesztés következett be

- a különböző filerendszerek adatvesztési aránya megegyezik az elterjedtségükkel, tehát a hiba a közös nevezőben keresendő: vmlinuz

- az itt használt ubuntu vote modult is valami linuxos gyerek fejlesztette, ugyanis 3+9+2+1+7+1+5+3+66+5 = 102% szavazott idáig...

[ hupexpertize© || hupdiploma || harmatgyenge || hupmérnökinfo ]

nem mindenhez, megnézem ki írta, milyen a környezet, hogy fogalmazott, de néha udvariasabban fogalmazok mint ahogy megérdemelné, pl mint most is

a szó szerinti kérdésed meg nem értem, mármint azt nem nézem ki belőled hogy nem tudod hogy jöhetett ez ki

de legyen: (100/6 kerekítve)*6=102

ps: na jó, ha beszéltetni akartál akkor legyen:)
a szék (pl parlamentben) darabban mérendő, se be nem tesznek újat,se üresen nem hagynak se nem darabolják fel, kiosztják valahogy és kész
a százalék (értelemszerűen valahány tizedes pontossággal) pedig arányt mond, ha gyerekeknek osztasz tortát mégis kiknek mondod hogy kevesebbet kapott mint a többi? mikor nem is adják össze, azt nézik hogy ö is meg a másik is 17-et kapott, az lenne a félrevezető ha miközben egyenlő lenne más szám lenne mellette
ez a különbség a százalék és a szék közt

Valamit félreérthettél, nem az volt a téma, hogy mi a számolás metodikája. De azért örülünk, hogy prygme után újabb user döngeti a mellét, hogy ifjúsága legkreatívabb éveiben produktív munka helyett inkább kiseggelt egy darab papírt.

[ hupexpertize© || hupdiploma || harmatgyenge || hupmérnökinfo ]

két dolgot láttam:
- ubuntus vote modul, linuxos gyerek
- egy összeg 102

két dolgot tudtam ebből kihámozni:
- 100-at várnál, azaz szidod az ubuntu-t meg a linuxosokat
- ész nélkül írogatsz

előbbi mellett döntöttem, tehát tévedtem, mert a számozás metodikája nem lényeges, de akkor mi volt a téma?
(mármint azon túl hogy ugye a fájlrendszerekről lenne szó!)

Alapvetően az volt a téma, hogy mennyibe fájna a kerekített értékekből 10 felé osztva levonni azt a 2%-ot és újrakerekíteni, elvégre már ennyitől is pontosabb lenne a számolás a mostani nevetséges szar helyett, meg nagy merészen még olyanra is tudok gondolni, hogy talán nem olyan sok binuxos embernek válna fossá a szürkeállománya, ha egyetlen tizedesjegy még oda lenne rakva a százalékokhoz.

Az okoskodva hülyeséget belepofázás megvolt, egyebet esetleg még kívánsz hozzátenni az élet dolgaihoz?

[ hupexpertize© || hupdiploma || harmatgyenge || hupmérnökinfo ]

hát eddig tartózkodni próbáltam hogy reagáljak, ezután nem is teszem mert csak értelmetlen off lesz, de még egy dologra rákérdeznék:

6 felé hogy osztod szét a 100%-ot?
(nem mennék bele hogy más eloszlásnál is értelmetlen a szétosztás, csak erre a 6-ra lennék kíváncsi)

((a tizedesjeggyel pontosítást elég nagy baromságnak tartom, miért pont eggyel? miért lenne pontosabb egy ilyen hihetetlen pontosságú mérés mint egy _szavazás_? szóval elég értelmetlen))

van 6 oprendszer mindegyik ugyanannyi szavazatot kap, tehát a fentebbi round(100/6)*6 példára gondolva:

szerintem inkább legyen mindegyik 17% minthogy azt mondja valamelyik hogy de én azért jobb vagyok
senki nem adja össze szavazásnál a számokat, az egymáshoz való viszonyt nézzük

nem vagyok jó számtanból, ez tűnt egyszerűnek fejben számolni és gondoltam nem függ az algoritmusod attól mennyi lehetőség van, szóval fenntartom és befejezem:

szavazásnál százalékon túl pontoskodni és ráadásul mindenáron 100-ra kihozva akarni az összeget beáldozva hogy két egyenlő szavazatot kapott lehetőségből önkényesen kiválasszuk hogy vajon melyik is kap azért mégiscsak többet,...
mindezt vagy pusztán hülyeségből vagy csak hogy megint mondhass egy példát hogy vajon kik írnak ilyen bénán ... nonszensz, ami kiváltotta ezt az utolsó szálat tőlem feléd

> szavazásnál százalékon túl pontoskodni és ráadásul mindenáron 100-ra kihozva akarni az összeget beáldozva hogy két egyenlő szavazatot kapott lehetőségből önkényesen kiválasszuk hogy vajon melyik is kap azért mégiscsak többet,...

Jahát igen, lehet a linuxos gyerekeknél az már hatalmas igényeskedés, hogy a százalék ne százkétalék legyen... Lásd: "az itt használt ubuntu vote modult is valami linuxos gyerek fejlesztette" 


	%		-1%/10		X		
18	2,932	3	2,832	3	17	2,815	3
53	8,632	9	8,532	9	52	8,609	9
10	1,629	2	1,529	2	9	1,490	1
4	0,651	1	0,551	1	3	0,497	0
43	7,003	7	6,903	7	42	6,954	7
4	0,651	1	0,551	1	3	0,497	0
27	4,397	4	4,297	4	26	4,305	4
15	2,443	2	2,343	2	14	2,318	2
411	66,938	67	66,838	67	410	67,881	68
29	4,723	5	4,623	5	28	4,636	5
614	100	101	99	101	604	100	99

hiába vontam le 1%-ot (látszik a 99-en) maradt kerekítve 101
aztán kipróbáltam hogy az eredeti adatból vonom le ez 1%-ot 0.6 kerekítve, azaz mindenkitől 1-et), akkor meg már 99-lett a vége
tökmindegy hogy rosszul értem-e, akárhogy akarod kivitelezni (láttam már működő módszert) akkor is kellenek plusz körök

nem akartam kitérni ilyen részletre hogy kivitelezés, mert a szándékkal volt bajom hogy minek akarsz ilyet

konkrétan az a homályos hogy ilyen osztogatós mókát oviban tanítanak a gyereknek a rókával, de rájönnek hogy nem marad nekik sajt

- elrontod a kerekítés előnyét (nem tüntet ki egyenlőség esetén valakit akit pl a felsorolás sorrendjével ki lehet választani)
- nem kell neked hogy az összeg 100% legyen sem
- plusz terhet raknál a szerverre, plusz kóddal (hwigény+megírni+hibalehetőség)
+ kiválasztasz egy "népcsoportot" akit lehet szidni vélt hibáért, vélve hogy az szokott ilyet (itt már legalább azt csinálod amit mondasz)
= ... hm tényleg gyenge vagyok számtanból

> - elrontod a kerekítés előnyét (nem tüntet ki egyenlőség esetén valakit akit pl a felsorolás sorrendjével ki lehet választani)

mit beszél a szájad

> nem kell neked

aham

> plusz terhet raknál a szerverre

beszartam

> kiválasztasz egy "népcsoportot"

pls no racial hatred here

> tényleg gyenge vagyok számtanból

known bug, wontfix, dontcare

> inkább kitérsz

Vélhetően azért van ez így, mert egyrészt ez a pont a főtéma szempontjából egy apró mellékszál, másrészt pedig nem gondolom, hogy pont egy matematikai javítást nem szar le mindenki. De hála a beleokoskodásodnak és a diplo^H^H^H^Hvégzettséges nyünnyögésednek, most remekül rommá beszéltük a semmit, yeah. :/

> nem tudsz összeadni
> nem tudod mi a különbség a százalék és a szék között
> ész nélkül írogatsz
> ott más is hiányozhat
> nem nézlek hülyének

válassza ki a kakukktojást Ön

[ hupexpertize© || hupdiploma || harmatgyenge || hupmérnökinfo ]

"a hiba a közös nevezőben keresendő: vmlinuz"

Te folyton viccelődsz... :-) Akkor ezek szerint az ext3.ko máris tuti. :)

Amúgy aki még ext2 időkben használt linuxot és nem volt adatvesztése, az vagy nagyon szerencsés, vagy már akkor költött szünetmentesre, vagy nem meri bevallani. Amikor diszkeditorral kellett pár fájlt összeraknom, Rémy Card biztosan nagyon csuklott. Aztán még xfs-sel is voltak apróbb bakik, de azóta semmi.
---
;-(

Ha nagyon oszinte akarnek lenni, az osszes, Unix alapu jogokat tamogato fajlrendszer elmegy a sunyiba. Az rwx jogrendszer loszart sem er egy picit is bonyolultabb kornyezetben (pl. fajlszerver). Nem tudom, miert nem lehet egy olyan szintu jogkezelest megvalositani, mint amit az NTFS megvalosit. Merfoldekkel hasznalhatobb lenne mindenfele Unix alapu rendszer, es nem azon kene sakkoznom, hogy most akkor kinek a tulajdonaba, milyen joggal rakjam a mappat, hogy irni-olvasni tudjak, de magat a mappat senki ne tudja torolni a root-on kivul.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ide irom, de az eredeti felvetesedre valasz:

ha az a celom, hogy egy mappa (becsuletes neve egy UNIX portalon: konyvtar) ne legyen torolheto, ellenben benne lehessen mindenfelet csinalni, akkor a szulokonyvtar irasjogat kell elvenni.

UNIX alapismeretek tanfolyam 3. nap - jogosultsagkezeles.

Ui: valoban van olyan, amit a hagyomanyos ugo/rwx -szel nem lehet megoldani, erre vezettek be az ACL-eket - de majd megnezem gabu kannibal leirasat, es revidealom az elkepzeleseimet.

Melyikből nem tudok törölni?

dir1 / dir2

Ha dir1-en veszed le az írásjogot, akkor dir2-t nem tudom törölni, de az, hogy dir2-ben tudok-e törölni/átnevezni, az már dir2 jogán múlik. (Most baromira leegyszerűsítettem a dolgot, mert még bele kellene keverni az X jogokat is.)

Ha elveszem a szulokonyvtar irasjogat, akkor ezzel tobb jogot veszek el, mint az adott mappa torlesere vonatkozo jog, ez esetben ugyanis a szulokonyvtarba nem lehet tobbe irni sem. Marpedig ez nem feltelten kivant mellekhatas.

Es hint: a POSIX ACL-ek ugyanugy csak rwx jogokkal szabalyoznak, ami meg mindig edeskeves.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ez igaz. Ellenben az eredeti kerdesedre kaptal megoldast. Az, hogy utolag tovabbi felteteleket adsz a kerdesedhez, arrol nem tehetek. Egyebirant pedig ahol ez komoly problema, ott be kell rakni egy bena kozbenso konyvtarat, es a problema ugrott :-)

A HINT: tekintve, hogy a hagyomanyos *X rendszerek nem definialnak onallo, es csak erre vonatkozo torlesi jogot, (ahogyan nem definialjak az onallo, csak erre vonatkozo pl. masolasi jogot, vagy a csak fajljellemzok allitasanak jogosultsagat sem), ezen rugozhatunk a vegtelensegig - ebbol a 3-fele jogbol kell gazdalkodni, es (esetleg) az ACL-ek segitsegevel megoldani a problemankat.

Es lehet azon sajnalkozni, hogy nincs ennel bosegesebb allitasi lehetoseget biztosito FS, de azert probald elkepzelni azt, hogy valaki csinal egy ilyet es aztan ahhoz hozza kell igazitani minden unixos alkalmazast, ami a mai napig ugo/rwx -ben gondolkodik. Nem lenne kis munka - de felek a vegeredmenyre a kutya nem mondana, hogy UNIX(-like).

"Es lehet azon sajnalkozni, hogy nincs ennel bosegesebb allitasi lehetoseget biztosito FS"
Van, NTFS a neve.

Hogy hozza kellene igazitani a mostani appokat? Nem feltetlen, amennyiben a rwx jog mellett jelennenek meg ezek a jogok, aki rwx-ben gondolkodik, az azt kap, de a normalis appok ugyis access(2) rendszerhivassal csekkoljak a jogokat, tehat elsosorban a mogottes rendszert kellene csak atirni.

Nem mondana senki, hogy UNIX(-like): felek, a Linux egyebkent is gozerovel csortet afele, hogy ne legyen UNIX-like, ezen mar tul sok mindent nem valtoztatna a dolog.
Egyebkent meg, nem tudom, miert cel az, hogy UNIX-like legyen a dolog. En tudom, hogy az UNIX jo volt meg szep volt, de szepen lassan ki kellene mar noni a hulyesegeit, mert az ido egyszeruen elrohan a fejunk felett. (Tudom, csinaljak jobbat.)
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

>> "Es lehet azon sajnalkozni, hogy nincs ennel bosegesebb allitasi lehetoseget biztosito FS"
> Van, NTFS a neve.

A szovegkornyezetbol ki kellett volna deruljon, hogy UNIX-like kornyezet alatt ertettem a dolgokat, de termeszetesen igazad van. Mindazonaltal egyelore nem lattam semmilyen UNIX-like kornyzeteben nativ-NTFS tamogatast, amire az emberek az adataikat is ra mernek bizni (mondjuk / , /boot, /usr es hasonlok). De ha a vilag ennyire nem toleralja az ugo/rwx -et, akkor eltelik egy-ket ev, es a legujabb Ubuntu mar nativan NTFS6-ra formazza a VXVM-es koteteinket a linuxos szerveren.

Ellenben egy kis ellenkezes:

> a normalis appok ugyis access(2) rendszerhivassal csekkoljak a jogokat

Az sajnos nem jo. Idezet man 2 access, FreeBSD: 


SECURITY CONSIDERATIONS
     The access() system call is a potential security hole due to race condi-
     tions and should never be used.  Set-user-ID and set-group-ID applica-
     tions should restore the effective user or group ID, and perform actions
     directly rather than use access() to simulate access checks for the real
     user or group ID.  The eaccess() system call likewise may be subject to
     races if used inappropriately.

Van ott mas is, de ez a lenyeg: ne ellenorizd elore, hanem probald megcsinalni az adott muveletet es korrekten kezeld le az esetleg visszakaphato EACCESS hibakodot. Azt, hogy sechole hogyan lesz, azt nem tudom, de mit fog kezdeni a szoftvered azzal, ha az access, es az ot valamikor kesobb koveto open (vagy barmi egyeb) muveleted kozott: remountolja valaki RO-ba az FS-t; chmod-dal megvaltoztatja a fajl vagy a path valamely tagjanak a jogat; chown-nal tulaj/csoportvaltas tortenik; es i. t.? Mivel az access fajlnevet var es nem FD-t vagy FILE* -ot, ezert ez a helyzet siman fennallhat. Mivel ez fennallhat, a szoftvered kenytelen lekezelni az open/egyeb eseteben az EACCESS hibakodot - node akkor mi a francnak probalta az access-t? (Speciel kb ugyanez a helyzet a stat(2)-vel is, de ott legalabb van fstat(2), ellenben faccess(2) nem letezik - meg ugy kb minek.)

Hat nem tudom, szerintem ha mindket megoldast alkalmazzuk, abbol nagy baj nem lehet, bar hogy sechole hogy lesz a dologbol, azt en sem tudom. A open/fopen hibas visszatereseit egyebkent is le kell kezelni, mert azok az EACCESS-en kivul barmi egyeb errno-val is visszaterhetnek.

Toleralja... ez van, a lehetoseg sincs meg masra, mert maga az egesz linux bele van ragadva ebbe az UNIX oroksegbe. Pedig nem lenne nehez kibujni belole, csak hat akkor nem lesz UNIX-like, es ez sokaknak bancsa majd a szemet.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( GCS v | 2010. 07. 28., sze – 07:23 )

Reiserfs halt már meg többször is (még kb 2000-es évek elején). XFS talán egyszer. Többi HDD badsector probléma volt. Egyik ilyen esetben valami alacsony szintű XFS tool-lal helyre sikerült állítani a tartalmat.