A ZFS nem lesz a Mac OS X "Leopard" alapértelmezett filerendszere

macOS

A korábbi napok pletykái ellenére biztos, hogy nem lesz a ZFS alapértelmezett filerendszer a Mac OS X következő kiadásában, a 10.5-ös verziószámot viselő "Leopard"-ban. A rémhírt Jonathan Schwartz, a Sun vezérigazgatója röppentette fel az elmúlt héten egy rendezvényen. Az Apple most cáfolta a Sun értesüléseit.

Az InformationWeek cikke szerint Brian Croll, az Apple egyik marketingvezetője cáfolta az értesüléseket. Azt nyilatkozta, hogy az Apple sose mondta, hogy a ZFS a Leopard része lesz. Croll szerint marad az a filerendszer, amelyet az userek eddig is használtak (HFS+). Később egy Apple-s szóvivő korrigált. Az Apple azt akarta mondani, hogy a ZFS elérhető lesz a Leopard-ban, mint limitált választási lehetőség, de nem lesz az operációs rendszer alapértelmezett FS-e. Bővebben itt.

( trey | 2007. 06. 13., sze – 08:53 )

És néhányan felsóhajtottak.

--
trey @ gépház

( zwei | 2007. 06. 13., sze – 08:58 )

Tulajdonképp nem értem, minek egy desktopba zfs. Szinte az összes olyan funkciója, ami miatt érdemes használni, leginkább nagyobb szerverkörnyezetben nyer igazán értelmet...

Értem. Esetleg nekem tudatlannak elmagyarázod, hogy mi az az Apple raid, mi köze van az Apple notebook-jaihoz, kiváltképp a G4-es iBook-okhoz, és az, hogy miért lesz jó a ZFS egy áltagos Mac OS X kliens felhasználónak? Mert erről még nem hallottunk, és erről szól ez a szál. Köszi.

--
trey @ gépház

Disclaimer: vigyazat, linuzfanboi szamara felfoghatatlan dolgok kovetkeznek, engedelyezem a felmondattal torteno elintezeset ;)

Annyira nem fogas kerdesek ezek, leven amint bebokom a firewire kabelt a G4 iBook-omba (match), rogton becsatolodik egy RAID0 es egy RAID1, amikkel dolgozni szoktam. A ZFS lesz akinek jo lesz, lesz aki leszarja mert a HFS+ sebessege es stabilitasa eleg, es nem kell plusz funkcionalitas.

A ZFS imho jo lesz nemcsak szerverre, de egy "atlagos" OSX-el dolgozo, es/vagy developpolo embernek is ha igenyli, pl nekem (sokkal jobb mint egy linuzosnak, akinek, ize... hat neki nincs ZFS, vallasi okok miatt), peldaul azert mert az apple raid nem felel meg.

( Gabucino | 2007. 06. 13., sze – 09:51 )

Jo hat az ilyen "minek linuxba scsi support, ha trey notbukba hasznalja" tipusu erveles elott fejet hajtok

( Gabucino | 2007. 06. 13., sze – 09:54 )

>(btw: firewire HDD Linux alatt out-of-the-box, FYI)

/me pets trey

Gondoltam megnézem az okostojás oldalát. Nem tudom, látta-e valaki Eben Moglen fotóját rajta, ezzel az aláírással: "Sose végezz félmunkát. Különösen Adolf Hitlernek szól ez."

Két megjegyzés:

- Ez a gyerek akkora állat, hogy minden civilizációs norma ellen szól vele akár csak szóbaállni is.
- A eset nyilvánvalóan kimeríti a közösség elleni izgatást és egyéb törvényi tételeket, így törvénysértő is.

Szóval ezt meggondolva próbálkozzon bárki vitába szállni vele!

Igen, ez kulonosen annak fenyeben erdekes, hogy az ominozus szerver a HBONE-on van, aminek pedig van egy egesz kedves kis AUP-ja, ami pedig legjobb tudomasom szerint az ilyesmit hatarozottan tiltja, de meg varom a NIIF CSIRT-es kollegak allasfogalasat a dologrol.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

na majd jon a zamboriz es kiegyenliti az eroviszonyokat ;)

attol, hogy neked kielegiti a reiserfs es gdesklets a desktop igenyeidet, attol meg lehet, hogy masnak vannak magasabb igenyei is, esetleg tenyleg jol jon nekik a zfs akar desktopon is. nem tudom ez teged miert zavar.

na de varjal, ne farasztd magad, kiexpektalom a valaszaidat, hogy tobb idod legyen masra:

t: na, pont te beszelsz a netbsd-vel, meg flash sincs linux emulacio nelkul bsd-n.
r: nekem nem is kell, nem hasznalok emulaciot, meg a gnash sem erdekel, mert ruhellem a flash-t.
t: persze, mert nem bsd licences, kulonben jo lenne
r: en nem vagyok licencbuvar, az a turul :)
t: na jo, en megyek ebedelni, ugysem erdekel ez az egesz zfs hulyeseg

kihagytam valamit? :)

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

>Backup. Ezer más megoldás létezik rá.

Nem is ertem az apple miert nem a freshmeatrol toborozza a killer ficsorjeit amikkel innoval

>Tömörítés. Akku-n?

Is that your best?

>Adatintegritás. Rendben. Szerintem ezért kár.

Vegyuk eszre hogy nem linuxrol van szo, ahol ez a szo valoban misztikum

Azért nem olyan fergetegesek ezek a vinyóméretek.
A tömörítés szerintem nagyon hasznos. Van egy rakás dokumentáció (Java APIdoc, html formátumú doksik), amit én így tartok a diszken, és jónéhány gigát meg lehet vele spórolni. Vagy ha logokat kell elemezgetni a notebook-on távoli elérés hiányában (nem tipikus feladat, de velem előfordult már), 4 gigányi log 1 gigába belefér, és ugyanúgy tudsz benne keresgetni. (Ugyan én NTFS-en teszem ezt, de az elv hasonló.)
Nyilván vannak elkerülő megoldások erre is, de ez baromi kényelmes. Szerintem reális igény desktopon, akár notebook-on is.

G4-en: nem ismerem a Mac-eket, de akár ott is. 386-on, 486-on nyilván megérezte az ember, de itt már nem.

a tömörítés márpedig nagyon hasznos tud lenni. pl 1 csóró diáknak nincs pénze 80 GB noebook hdd-re ha a sok szart fel akarja tömni a notebookjára. Amúgy meg: minek pazaroljuk az erőforrásokat? Ez a föld erőforrásaira is vonatkozik, meg az ilyen absztrakt erőforrásokra is.

Amúgy ha tudsz 10k hufért 80GB noti HDD-t, újan, garival, alacson fordulatszámmal...afával... akkor jó neked.
---
Reactor error - core dumped!

az a baj, hogy folyamatosan a szerint ervelsz, hogy minek megcsinalni valamit amire van mas megoldas. ilyen alapon soha ne csinaljon senki ujat, mert minden mukodik mar most is, vagy meg lehet oldani valahogy. a kereket se ertem minek fedeztek fel, szantalpakon is lehet szallitani dolgokat. persze, most minden ficsor egy fsben nem lesz ilyen kaliberu, nagyresze lehet ertelmetlen, de hasonlitsd a ket ervelest:
1. miert csinalnak - meg lehet maskent is.
2. miert csinalnak - mert kepesek vagyunk ra.

nekem a masodik sokkal jobban bejon, mert az elso hosszutavon stagnalashoz vezet. igenis jo, hogy ugyanazt a dolgot szazszor meg szazszor ujramegoldjak, igy lesz mukodokepesebb, felhasznalobaratabb. az sem baj, hogy olyan helyeken hasznalnak dolgokat amik elsore nem tunnek logikusnak. gondolj csak bele a kezdeti kameras telefonokra. micsoda hulyeseg. hasznalhatatlanok voltak barmire. most viszont igenis kezd ertelme lenni, hogy legyen a telefonodon ez is meg az is.

miert dontened el te elore egyenkent, hogy valaminek van ertelme vagy nincs? persze, ha te kell megcsinald az mas, az a te dolgod. de masokra is nyugodtan rabizhatod, mert az meg az o dolguk. ne aggodj, ha neked van igazad es folosleges a desktopra a zfs ugyse fogja hasznalni csak egy igen kis reteg. nem a te veszteseged ez, vagy igen?

Én a saját véleményemet mondtam el a saját tapasztalataim alapján. Megkérdeztem, hogy milyen érvek szólnak mellette desktop-on. Volt aki makogott, megvédeni nem tudta. Volt aki mondott valamit, ami szerintem annyit nem ér, hogy 8 féle filerendszerrel szarozzon valaki. Ha szerinted ez jó, akkor használd. A választás a tiéd.

--
trey @ gépház

korrekt valasz, csak nem ertem miert kell egyaltalan keresni az erveket. egy idoben en is ezt csinaltam, es ma nem ertem miert. hol faj nekem az, hogy ki mit miert hasznal vagy nem hasznal. ja. ott amikor ie-t hasznal a tobbseg, hogy tobbett kell melozzak :D. de amikor nincs meg ez a szoros kapcsolat a masok altal hasznalt programok, hardverek es a penzugyi vagy egyeb helyzetem kozott akkor leszarom. ha ok notebookban akarnak zfst annak minden ficsorjevel, hat rajta. a tomoritest pl en is megertem, gondolhatod, hogy nem mindenki ad ki 10 giga plusz helyert penzt egy 80 gigas vinyora. meg akkor sem, ha amugy lenne ra penze. :)

nah de akkor megbeszeltuk, cska valahogy te is meg Gabu is eloszeretettel beszeltek el egymas mellett. aztan az artatlan kulso szemlelo csak kapkodja a fejet mint egy asztalitenisz meccsen a nezok.

nekem ne mondd, jol vagyok a 6310i vel. viszont lattam telefont ami jo kepet csinalt este, amikor hirtelen kellett valamirol fenykep, es azt mondtam, hogy igen, lehet ertelme. van mire hasznalni, ha valakinek pont ez kell.
egyszeruen a mellett ervelek, hogy csak azert mert valamit en vagy te vagy akarki ertelmetlennek tart nem jelenti azt, hogy ne csinalja meg mas. vagy hogy masoknak nem az a legnagyobb szivuk vagya amit mi leszarunk. ez nekem nem faj. nem kerem, hogy elmagyarazza, hogy miert pont zfs kell neki. legyen. hasznalja, oruljon. sokkal jobba nekem, ha az ismeroseim(es nem csak) orulnek valaminek aminek en semmi ertelmet latom, de szamomra nem artalmas, mint az ellenkezo eset.

Hát én nem akarok beleszólni, de pl a gzip elég transzparensen használható ha szövegekről van szó.
less, grep, cat van gzip-et támogató verzióban is, sőt a bzip2 is elég transzparens ilyen szempontból.

A binárisokat (libeket pl.) úgyse érdemes tömöríteni, mert azzal a betöltési idő hosszabbodik meg.

Ja, és gentoo alatt a less natíve támogatja a (g|b)zipet. nem kell zless-t használni.
Szal ennyit a transzparenciáról.
editálás után így is-úgy is recompression megy végbe bármit csinálj.

Btw a folyamatosan íródó logfájloknál még talán picivel lassít is a FS-level compression, de ez már szigorúan szvsz és nem feltétlen van igazam.

gzip transzparensen használható.. less-el.

és ha én ilyet akarok:

gcc -o bla bla.c.gz

ilyenkor lenne jó a tömörítés. ráadásul a sok kis file (<=blocksize nem foglalna egész blockokat, ha az FS jól van megtervezve/megcsinálva)
---
Reactor error - core dumped!


gzip -dc x.c.gz | gcc -x c -o x.o -c -

De mondjuk a fenti példa megint csak inkább a gcc baja. Sztem azért nincs ilyen feature a gcc-be mert senki nem lobbizott érte. Itt a soha vissza nem térő alkalom!

A másik ok talán az editorok általi nem-supportáltság. Ennek ugye mint fentebb írtam a recompression lehet a gondja - és ez a FS-nél is fellép (persze ugye ez esetben a szoftver számára transzparens a dolog). De tévedjek.

Ja, és gentoo alatt a less natíve támogatja a (g|b)zipet. nem kell zless-t használni.
Szal ennyit a transzparenciáról.
editálás után így is-úgy is recompression megy végbe bármit csinálj.

Ez valoban komoly erv. :)

A tobbihez: csak gondold azt az apro dolgot at, hogy a mai processzorok atlag 2GHz korul vannak, a ram modulok 667MHz korul rohangalnak, addig egy jobb vinyo alig visz at 80MB/secet szekvencialisan olvasva.

Mi gyorsabb:

- mindent rawban olvasni vinyorol
- vagy atlag 25-50%-os tomorites eseten ketharmad/fele annyi adatot lerantani a lassu disk alrendszerrol es tobbit on-the-fly kiromoriteni?

En az utobbira szavaznek. Anno pl. MPEG2 tomorites eseten csak egy erv volt a kisebb meret. A masik, hogy nincs az a DVD ami 720x526x[12-16bit]x[23-30] mennyisegu adatot at tudna huzni masodpercenkent. :)

---
pontscho / fresh!mindworkz

Mi a jobb notebooknál? +10 ezer forintért venni 2x akkora vinyót, és cserébe hosszabb üzemidő, halkabb és hűvösebb gép, vagy pörgő processzor mellett állandóan üvöltő gép, soha nem pihenő processzor, vasaló effektus.

Illetve, ha nincs +10 ezer, akkor megelégedni a 80 GB-nyi lemezzel (jelenleg standard méret). A mobilitás (== üzemidő) a legfontosabb tulajdonsága a _mobil_ gépeknek.

A szál még mindig arról szól, hogy miért jó a notebook felhasználónak a ZFS, és nem arról, hogy miért jó a ZFS úgy általában.

--
trey @ gépház

Jo, akkor egy egyenes valasz, hogy legyen nemi meglepetes is: notbuknal ket szempont van:
- elsodlegesen anno ennel a koncepcional nem az aksi ido volt a lenyeg, hanem a mobilitas, ha ezt veszem alapul, akkor azt hiszem a valasz adott
- masodsorban ujabban az alkalmazhatosag elmozdult az elobbi pontrol a barhol/barmikor mukodes fele, es ott valoban az akkumulatorrol valo hosszabb uzemido az elsodleges, es oda nem optimalis egy folyamatos CPU igenyu cucc.

---
pontscho / fresh!mindworkz

Mi a betegséged?

Nekem ez volt a kérdésem:

"Mi a f@szt fog csinálni a notebook-jában az egy darab lemezével "ZFS a kirrajjj" Mac OS X kliens játékos."

Te az én postomra válaszoltál. Mit válaszoltál? Folyamatosan félrebeszéltél, míg én folyamatosan erről. Ha te nem erről akartál beszélni, hanem zwei komával a desktop témáról, akkor tanulj meg thread-be válaszolni.

--
trey @ gépház

Bocs, de sztem te olvastad félre. Ő csak mellékesen megemlítette, hogy az szerinte inkább szerverekbe való feature, és az ő meglátása szerint a notebookokban nincs haszna. Ha esetleg visszagörgetnél az elejére...
Ja, és csináljatok valamit, fogy a hely...

Szerintem ez nem szemüveg kérdése. Én azt figyeltem meg, hogy a kötekedésen kívül semmilyen értelmes célja nincs az egésznek. Nem egészséges viták alakulnak ki egy-egy dologról hanem rögtön személyeskedés lesz belőle.

Baromira irritáló de _sajnos_ el kell viselni...

--
maszili

Te,m szerintem a tömörítés bármely algoritmus esetében processzoridőt von el, ergo ha bitre megmérnéd, a raw olvasás mindenképp gyorsabb.

Arról nem beszélve, hogy a tömörítéshez eszméletlen diskcache is kell, hiszen elsőre nem tudhatod mennyi adatot kell ki-be tömörítened, pláne random olvasáskor (ugye egy fs nem feltételezhet kizárólagosan sequential olvasást). És a fájlrendszer nem válogathat, hogy ő csak azokat tömöríti, amit szöveges fájlnak ismer fel. Akkor mán a bináris fájlokat is tömnie kell. Sajna a átlagjuzer nem csinálja azt , hogy jó, akkor a mp3 fájlokat a másik particióra teszem, mert az gyorsabb...
Jó, persze, iszónyú mennyiségű memóriák vannak manapság a gépekben - de elsősorban nem azért, hogy az oprendszer lenyúlja a felét.

Szóval azért vannak itt korlátok/gondok rendesen.

Akkor mán a bináris fájlokat is tömnie kell. Sajna a átlagjuzer nem csinálja azt , hogy jó, akkor a mp3 fájlokat a másik particióra teszem, mert az gyorsabb...
Jó, persze, iszónyú mennyiségű memóriák vannak manapság a gépekben - de elsősorban nem azért, hogy az oprendszer lenyúlja a felét.

Pedig az OS lenyulja a felet manapsag is. Minden rendes OS dinamikusan kezeli ezeket a keseket, es a szabad ram automatikusan read cache lesz. :) Ergo a fentebb olvashato erv is elenyeszo lesz. Manapsag 1GB ram alatt aki gepet vesz azt siman lehujezik, szerverekben pedig minimumnak szamit.

Amugy inteligensen el lehet donteni, hogy egy adott adatot erdemes-e tomoritve tarolni vagy sem. De ennyi inteligenciat azert feltetelezek a SUN mernokeirol. :)

---
pontscho / fresh!mindworkz

Te,m szerintem a tömörítés bármely algoritmus esetében processzoridőt von el, ergo ha bitre megmérnéd, a raw olvasás mindenképp gyorsabb.

Ez akkor lenne igaz, ha a processzor és a merevlemez ugyanakkora adatmennyiséget tudna azonos idő alatt mozgatni... ;)

Arról nem beszélve, hogy a tömörítéshez eszméletlen diskcache is kell, hiszen elsőre nem tudhatod mennyi adatot kell ki-be tömörítened, pláne random olvasáskor (ugye egy fs nem feltételezhet kizárólagosan sequential olvasást).

Ahogy az írás/olvasás, úgy a tömörítés is blokkokban történik, így egyrészről nem kell "eszméletlen" disk cache, másrészről nem szekvenciális olvasás esetén sem kell nagy adattömeget feldolgozni egy "random" helyen lévő adat miatt.

És a fájlrendszer nem válogathat, hogy ő csak azokat tömöríti, amit szöveges fájlnak ismer fel. Akkor mán a bináris fájlokat is tömnie kell.

... Aztán amikor (a memóriában) letömörítette az adott blokkot, akkor egy hihetetlen innovatív feltételes utasítással eltudja dönteni, hogy a tömörített blokk kisebb-e, mint az eredeti. Ha nem, akkor az eredetit írja ki és így visszaolvasáskor már nem kell tömörítéssel foglalatoskodnia... Nem semmi, mi? ;)

Sajna a átlagjuzer nem csinálja azt , hogy jó, akkor a mp3 fájlokat a másik particióra teszem, mert az gyorsabb...

A tömörítés nem per-partíció függő, fileonként (és rekurzívan könyvtáranként) szabályozható (gyakorlatilag egy flag beállításával, vagy Windowsosan szólva attribútum módosításával ;) és mint fentebb már mondtam, blokk-szinten történik az egész, ezért csak akkor történik meg a tömörített blokk eltárolása, ha azzal valóban helyet lehet spórolni.

Jó, persze, iszónyú mennyiségű memóriák vannak manapság a gépekben - de elsősorban nem azért, hogy az oprendszer lenyúlja a felét.

A transzparens tömörítéshez minimális memóriára van szükség, a disk cache pedig jelenleg is felhasználja a rendelkezésre álló szabad memória nagy részét.

Szóval azért vannak itt korlátok/gondok rendesen.

Vagy csak nem értesz hozzá eléggé és saját kútfőből próbálod kitalálni hogyan működhet ez az egész dolog, majd magadban lenyugtázod, hogy biztosan nem jó és kész... :)

Persze így is lehet.

Hát, töredelmesen bevallom, valóban nem írtam még tömörítésre képes fájlrendszer szerűséget, és nincs is szándékomban. :)

Valóban vannak dolgok amiben tévedtem, belátom, elnézést kérek, és köszönöm a kiigazításokat, megszívlelem.

Ezzel együtt:

... Aztán amikor (a memóriában) letömörítette az adott blokkot, akkor egy hihetetlen innovatív feltételes utasítással eltudja dönteni, hogy a tömörített blokk kisebb-e, mint az eredeti.

Aham... csakhogy akkor már megdolgoztatta a procit a tömörítés műveletével. Notebboknál nem az a lényeg hogy a processzor minél kevesebbet dolgozzon? Jó, persze, innentől tegyünk nocompress flaget a partícióra a partíció gyökerénél, és problem solved, de akkor is... Nem tudom, hogy ez miért jó.

Tévedés ne essék, én el tudom képzelni a FS-level compression létjogosultságát, de nem feltétlen desktop környezetben.

>> én el tudom képzelni a FS-level compression létjogosultságát, de nem feltétlen desktop környezetben.

mivel ez messze nem mai technológia desktopon*, abban a szerencsés helyzetben vagyunk, hogy nem kell hosszasan filozofálgatnunk a létjogosultságán

*desktopon

Azért nincs bekapcsolva, mert vannak neki hátulütői. Több, mint az, hogy elméletben nyerhetsz vele x MB-ot. Akkor nyerhetsz vele, ha jól tömöríthető file-okat tárolsz. Jellemzően a mai népszerű fileformátumok már tovább nem/nem jól tömöríthetők (önmagukban tömörítettek), ezért baromság alattuk bekapcsolni a filerendszer tömörítést. Szóval hacsak nem plain txt-t, vagy SQL dump-ot tárolsz (ja, ez jellemző) terabyte szám a gépeden, akkor érdektelen. Szóval kicsi az esélye, hogy haszna is lesz, ellenben nagyobb a valószínűsége, hogy csak:

- performancia problémáid lesznek, ha olyan file-okról van szó, amit sokszor használsz (állandóan ki be kell tömöríteni)
- éppen ezért például nagyforgalmú fileszerverre a Microsoft nem is javasolja
- a tömötrített file-ok csak addig tömörítettek, amíg NTFS partíción vannak, azaz ha hálózatra lapátolod szintén ki kell őket tömöríteni
- Exchage alá kimondottan ellenjavallt (sem a store, sem a tranzakciós logok alá), kivéve az SMTP logokat, de ugye ide ágyúval verébre
- egyes adatbázis-kezelők szintén nem díjazzák
- továbbá a tömörítéssel egyes programoknak problémája lehet
- 3rd party alacsonyszintű lemezkezelés végző programoknak szintén
- tömörített meghajtó esetén egy filerendszer probléma után a visszaállítás nehézkesebb lehet
- NFTS-tömörített meghajtón levő fileokat nem lehet titkosítani

És még lehetne sorolni az ellenjavallatokat. Mindezt miért cserébe? Hogy megtakarítsünk egy kis helyet. Köszi, de kösz nem.
--
trey @ gépház

Semmi, használjad sokat. Nekem az a véleményem, hogy nem éri meg (nincs új a nap alatt, olyan lenne ez mint az alkímia, hogy szarból aranyat (kedvedért: ingyen plusz merevlemezterületet, hátulütők nélkül)) csináljunk.

Helyette ("az ágyúval verébre FS tömörítés ismert hátulütökkel" megközelítés helyett), majd "tömörítek ha akarok, és akkor, amikor én akarom (jellemzően, amikor nem okoz nekem problémát)" eljárást választom. Nagyszerű programok érhetőek el erre.

--
trey @ gépház

Eddig azon lovagoltál, hogy a ZFS is minek _desktopra_, majd ez az egész továbbment azzal, hogy támogatja többekközt a transzparens tömörítést, de szerinted ez is baromság, végül előhozod, hogy nem _desktop_, hanem _szerver_ környezetben mikor és miért nem javallt... Nem rossz! ;)

Nem, én azt hoztam elő, hogy szerveren egyáltalán nem, de desktop-on _sem_ látom semmi értelmét. Főleg nem mobil gépen. A Windows-on sem, pláne nem, hogy a tömörítésért cserébe fel kell áldozni olyan dolgokat desktop-on, mint a titkosítás, amely egy mobil gépnél rendkívül hasznos feature.

Szóval: részemről FS tömörítés se desktop-on, se szerveren.

--
trey @ gépház

Azért volt ezt így veled meg Pontscho-val végigcsinálni, mert pont ti ketten voltatok azon, hogy minek a swap azért, hogy még egy kicsit több programot tudjon futtatni a rendszer. Ki kell kapcsolani. Inkább vegyünk még RAM-ot! volt a felkiáltás, hiszen a swap lassítja a rendszert, RAM olcsó. Na, most, hogy én hoztam fel ezt a FS tömörítéssel kapcsolatban (vegyünk inkább diszket, minthogy bohóckojunk az ilyen kétséges tömörítésekkel, ami inkább lassít, mint ér valamit), ez nektek nem tetszeik, mert a nagyszerű Leopard vaporware (egyelőre legalábbis úgy fest) ZFS-e ellen szól. Egy kicsit több következetesség nem ártana.

--
trey @ gépház

Már megválaszoltam, lásd lentebb... A rendszerpartíción is olyan dolgokra érdemes bekapcsolni, amelyeket nem használ a rendszer túl gyakran, viszont jó, ha kéznél van. És lám, a dllcache, meg a Windows Update Backup pont ilyen. Úgy tűnik az MS-nél sem csak hülyék ülnek a székekben, még ha most te próbálod is a dolgot csűrni-csavarni. :)

Aham... csakhogy akkor már megdolgoztatta a procit a tömörítés műveletével. Notebboknál nem az a lényeg hogy a processzor minél kevesebbet dolgozzon?

Ezért érdemes olyan fileokra/könyvtárakra engedélyezni csak a tömörítést, amelyikekre érdemes (tehát van pozitív hatása, előnye). Több gigányi dokumentációra vagy logokra beállítva elég sok helyet lehet vele spórolni. Ezeket egyébként sem nyitogatja az ember óránként, csak nagyon ritkán, viszont jóval több szabad háttértár áll rendelkezésedre a nap 24 órájában cserébe. Nyilván programokra, főleg amelyeket gyakran hívogat az ember (vagy a rendszer) meg a függvénykönyvtárakra nem biztos, hogy érdemes. Valószínűleg azokon is tudna tömöríteni, de jóval kevesebb helyet lehet vele felszabadítani, mint amennyivel többet dolgozna a processzor. Nem lenne arányban a befektetett processzoridő a megspórolt hellyel. :) Ezért is nincs alapértelmezetten bekapcsolva ez a szolgáltatás a filerendszerben.

Őő, nálunk nincs megszabva, hogy ki mit tarthat a céges gépén.

MP3, fényképek, videók, ISO image-ek, dokumentumok (jól tudom, hogy az .odt már ZIP tömörített formátum?). Logfile, simpla szövegfile sajnos nem sok van. Ami van (logfile), azt a logrotate tömöríti. Azon gondolkozom, hogy hol lenne itt értelme.

--
trey @ gépház

Én igazából tömöríteni nem nagyon szoktam. Van azonban egy olyan dolog, ami miatt néza használom. Ez a sok apró file labdába gyúrása (ne legyenek szanaszét). Ilyenkor beleteszem a tar-ba a "czvf"-et, de ez ingább megszokás. Tehát nem is igazán a hely miatt, hanem azért, hogy egyben legyen.

--
trey @ gépház

MIME típusok? pl az alajáán lehet dönteni: csak szöveg jellegű filokat próbáljuk meg egyáltalán tömöríteni. a többire vannak specializált tömörítési eljárások.
Ezzel rengeteg filet kizárnánk az alapértelmezett tömörítésből... sok potenciálisan jó alanyt is (pl nem kap kiterjesztést-> nem tujuk kéne-e tömöríteni) valamint kézzel ki/bekapcsolhatóvá, szelekciót beállíthatóvá tevő funkciót is lehet implemetálni. (pl mint ntfs-nél)

I/O wait?
addig meg potyára jár a proceszor. ahelyett számolna. és mérni kéne, nem a szájunk tépni, de linuxra pl _nincs_ egy értelmes, rw, tömörítést tudó filerendszer (és nehogy valaki itt előjöjjön a fuse+ cd qqriq.tgz -vel...). egyáltalán nem biztos, hogy lassulna a rendszer tőle... az akuidőt meg megintcsak mérni kéne.

Amúgy desktopon talán a legnygyobb a létjogosultsága, és nem is helytakarítás, hanem a gyorsítás szemponjából (csak 1 gyors algoritmus kell... nema is feltétlen tömörítés a lényeg, az a plusz nyereség) mert a felhasználónak _átlátszó_ módon (és a software-nek is) biztosítja az előnyöket.
---
Reactor error - core dumped!

100 GB-os diszk van a notebookomban, ennél talán 20 GB-tal tudnék most nagyobbat venni. Viszont fent van lényegében a gépen az egész életem, több tíz gigabyte-nyi (saját és egyéb) doksi. Ezek tömörítve jóval kevesebbet foglalnak és bármikor velem vannak, ha kellenek.

Mindenki másra használja a gépét, ha te nem tárolsz jól tömöríthető anyagból sokat, nyilván haszontalan ez a feature. Nekem nem az.

Snapshot: közepesen. Például mentéshez szerintem elengedhetetlen, de általános felhasználás mellett is hasznos egy olyan funkció, amellyel pld. adott fájlok előző állapotait vissza tudod hozni és ezt nem neked kell kézzel csinálnod.
Pld. módosítgatsz egy doksit, de valahogy nagyon elkúrtad, ilyenkor jó lenne visszaállni kettővel, de közben lerohadt a word, stb.

Tömörítés: a notebookomon a teljes adatpartíció tömörítve van. A több kevesebbért szerintem mindig jól jöhet. Illetve a notebookban a diszk io kisebb, mint a CPU kapacitás, tehát egy megfelelő implementáció mellett még akár gyorsíthat is.

Csak egy elég hétköznapi példát hozok fel:

Ha próbáltál már adminisztrálni olyan környezetet, ahol közös SAN-os storage-ot használt 4-5 szerver, 8-10TB aggregált tárkapacitással, és kb 100-200 file rendszerrel, akkor felcsillanó szemekkel fogadsz egy olyan megoldást, ami lehetővé teszi, hogy a felhasználóktól folyamatosan bejövő változtatási igényeket gyorsan és egyszerűen kiszolgáld, és ne kelljen folyamatosan LUN-ok, subdiskek és volume-ok méretezésével baszakodnod.

Lehet, de akkor mondd meg mit.

"
Tulajdonképp nem értem, minek egy desktopba zfs. Szinte az összes olyan funkciója, ami miatt érdemes használni, leginkább nagyobb szerverkörnyezetben nyer igazán értelmet..."

Tehát akkor újra. Melyik funkcióját?
"

Azt kérdezted (szerintem), hogy a zfs-nek melyik funkciója az, ami nagyobb szerverkörnyezetben nyer értelmet.

Erre az én válaszomban burkoltan az a ZFS feature volt benne, ami integrálja a file rendszeri és volume manageri funkciókat, aminek segítségével egyszerűbbé válik a fenti példában említett közepes nagyságú szerverkörnyezet file-rendszer és storage adminisztrálása.

"Azt kérdezted (szerintem), hogy a zfs-nek melyik funkciója az, ami nagyobb szerverkörnyezetben nyer értelmet."

Fals. Akkor lebábozom neked:

Te írtad:

"Tulajdonképp nem értem, minek egy desktopba zfs. Szinte az összes olyan funkciója, ami miatt érdemes használni, leginkább nagyobb szerverkörnyezetben nyer igazán értelmet..."

Én írtam:

"A múltkor ezt kérdeztem én is. Mi a f@szt fog csinálni a notebook-jában az egy darab lemezével "ZFS a kirrajjj" Mac OS X kliens játékos. Valószínűleg a cél nem is igazán ez, hanem a szervereik. Itt meg matyiznak rá ész nélkül a G4-es iBook-kal a kezükben."

Mrev írta erre:

"Mit fog csinálni? Tesztelni fogja."

Én írtam rá:

"Tehát akkor újra. Melyik funkcióját?"

Azaz a kérdés az volt, hogy melyik funkcióját fogja tesztelni ___desktop-on___. A te kérdésedet azért ideéztem, mert úgy látszik elsikkadt a lényeg.

(Következésképpen, mi ketten úgy tűnik egyetértünk.)

--
trey @ gépház

Lehet, de akkor mondd meg mit.

"
Tulajdonképp nem értem, minek egy desktopba zfs. Szinte az összes olyan funkciója, ami miatt érdemes használni, leginkább nagyobb szerverkörnyezetben nyer igazán értelmet..."

Tehát akkor újra. Melyik funkcióját?
"

Azt kérdezted (szerintem), hogy a zfs-nek melyik funkciója az, ami nagyobb szerverkörnyezetben nyer értelmet.

Erre az én válaszomban burkoltan az a ZFS feature volt benne, ami integrálja a file rendszeri és volume manageri funkciókat, aminek segítségével egyszerűbbé válik a fenti példában említett közepes nagyságú szerverkörnyezet file-rendszer és storage adminisztrálása.

imho azt kérdezte, hogy minek desktopra,

... leginkább nagyobb szerverkörnyezetben nyer igazán értelmet...

azaz tisztában van vele, hogy szerverkörnyezetben értelmes, a kérdés az az, hogy desktopra mifaxnak, miért előnyös desktopon.

Gabu leírta, hogy neki miért lesz überség, ha használhat zfs-t, ez ok.

"Túl átvitt értelmű volt a post, az én szerény értelmi képességeimnek. :)"

Igen, rájöttem én is, sokszor az a baj a postjaimmal, hogy feltételezem, hogy mások is egyből levágják a mögöttes dolgokat. Ez nem mindenkinek megy egyből. Életben értetted volna elsőre. Ez az internet egyik hibája.

--
trey @ gépház

Még szerencse, hogy éppen én mondtam az elején, hogy:

"A múltkor ezt kérdeztem én is. Mi a f@szt fog csinálni a notebook-jában az egy darab lemezével "ZFS a kirrajjj" Mac OS X kliens játékos. Valószínűleg a cél nem is igazán ez, hanem a szervereik."

Mintha kezdenél egy kicsit belekeveredni ebbe.

--
trey @ gépház

( mrev | 2007. 06. 13., sze – 10:09 )

Mit jelent közelebbről a "transactional semantics": Jelenti-e, hogy a POSIX write függvény mellett megjelenik valamiféle commit/rollback?

--
CCC3

( turul16 v | 2007. 06. 13., sze – 12:18 )

Ha ZFS implementáció tudja azt, hogy ha parhuzamosan 20 cp -t kiadok, akkor gyorsabban végez mindel, mint az edigiek és nagyábol többi teszten is hozza az átlagosnak számító értékeket, akkor van értelme beszélni róla desktopon.

Milyen isten csaszar dolog, hogy ezt 3 kulonallo modullal kepes csak ugyanolyan(?) minosegben hozni, amibol az utobbival anno akkorat szoptam, hogy azota maximum csak rohogok ha szoba kerul. (Kijavitottak mar azt a bugot, hogy ekezetes filenev eseten olyan menthetetlenul bele fagy az egesz, hogy utana nem kepes semmi mountolni azt a particiot?:)

---
pontscho / fresh!mindworkz

És azt a hibát vajon már javították benne, hogy rádobva egy MySQL-t, megnyomva a terhelést leáll minden disk-I/O; még fizikailag más lemezeken is? :)

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Nekem tök mindegy, hogy ki nem támogatja. Engem mint solution-t nem érdekel egy félmegoldás. Hasonlóképpen, mint a "tök jó a MINIX, igaz, programok nincsenek rá, de ez nem az ő hibája, a programozók nem támogatják". Részemről a MINIX innetől egy technikai érdekesség pusztán, nem több.

--
trey @ gépház

2007, március 29 - ZFS boot támogatás x86/x64-en, írta: trey :)

(Extra bonus: "A build 62-től integrálásra került a ZFS-be az lzjb mellé a gzip tömörítési támogatás. Használatával nem csak helymegtakarításra van lehetőség az alkalmazások számára transzparens módon, hanem bizonyos terhelések mellett (ha van elegendő CPU idő) akár gyorsíthaja a lemezhozzáférést is.")

( uid_228 | 2007. 06. 13., sze – 13:33 )

A default ZFS helyett minden Leopard média mellé fekete garbópulóvert, csíkszemüveget és kihajtogatható, papírmasé Starbucksot adnak, hogy a creative professional megfelelően inspiráló környezetben tudjon dolgozni. :)

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

( ng | 2007. 06. 13., sze – 15:02 )

off
kéne valami szkript az offtopik szálak szűrésére is
/off

( kalo (nem ellenőrzött) | 2007. 06. 13., sze – 16:59 )

ROTFL, ez a téma nagyon jó! :D

Az, hogy a linux stabilabb, mint a többi rendszer, már régóta csak legenda, lassan az XP is tovább bírja. A linuxos ha új dolgot lát (főleg ha cég írta és/vagy nem GPL), akkor rögtön azt mondja, hogy ő nem használja, tehát felesleges. Ez ám a fejlődés. ;)

---
"A pokolba vezetô út is jó szándékkal van kikövezve ..."

A tizenkétéves technológiákat tartalmazó FreeBSD-be meg távirati sebességgel portolták a ZFS-t, míg a linuxosok azon gondolkoznak, hogy lehetne legalább valami userspace drivernek megcsinálni.
Savanyú a szőlő, kérem.
It doesn't matter if you like my song as long as you can hear me sing

Nyilván 12 év múlva, mivel a ZFS mai technológia.
Akár így, akár úgy, még mindig jobb, mint a "talán userspace-ben esetleg"-téma.
Ja, és ha a Linux fényévekkel a többi opensource Unix előtt jár, akkor miért attól hangos az egész opensource világ, hogy Linusék azon izgulnak, hogy vajon a *** Solaris GPLv3 lesz-e, mert ők attól teszik függővé a váltást?
It doesn't matter if you like my song as long as you can hear me sing

"Nyilván 12 év múlva, mivel a ZFS mai technológia."

Nem vagyok jövőbelátó, de addigra a ZFS már elavult technika lehet.

"Akár így, akár úgy, még mindig jobb, mint a "talán userspace-ben esetleg"-téma."

A Sun még nem döntött. Nem zárta ki a GPLv3, de a GPLv2 alatt kiadott kód lehetóségét sem. Én még nem kapkodnék a helyedben.

"Ja, és ha a Linux fényévekkel a többi opensource Unix előtt jár, akkor miért attól hangos az egész opensource világ, hogy Linusék azon izgulnak, hogy vajon a *** Solaris GPLv3 lesz-e, mert ők attól teszik függővé a váltást?"

Technikai aspektusból - mint ahogy Schwartz azt elmésen megjegyezte (Are we after your drivers? No more than you're after ZFS or Crossbow or dtrace - it's not predation, it's prudence.) - mindkét fél (Linux, OpenSolaris) számára lehetnek olyan dologok a másik portékájában, ami érdekes lehet a másik fél számára. Linus egyértelműen megmondta, hogy a Solaris core nem érdekli, az egyetlen dolog, ami miatt esetleg újralicencelne, az a ZFS. Az OpenSolaris-nak meg éppen más kéne a Linux-ból. Ettől még a Linux jelenleg _szerintem_ jobb helyzetben van sok szempontból, mint a Solaris. Természetesen itt nem a bennük levő technológiákra gondolok elsősorban.

--
trey @ gépház

Nem vagyok jövőbelátó, de addigra a ZFS már elavult technika lehet.

Nem vetted fel a kesztyűt. ;-)

A Sun még nem döntött. Nem zárta ki a GPLv3, de a GPLv2 alatt kiadott kód lehetóségét sem. Én még nem kapkodnék a helyedben.

De eddig folyamatosan az ment, hogy milyen jó FUSE-modulnak a ZFS. :-P

az egyetlen dolog, ami miatt esetleg újralicencelne, az a ZFS

Ha jobban meggondolom, ez a Linux által jelenleg normálisan támogatott fájlrendszerekre nézve kurva nagy alázás.

a Linux jelenleg _szerintem_ jobb helyzetben van sok szempontból, mint a Solaris.

Ebben megegyezhetünk, szerintem is már csak állóhely jutott nekik a vonaton.

It doesn't matter if you like my song as long as you can hear me sing

"De eddig folyamatosan az ment, hogy milyen jó FUSE-modulnak a ZFS. :-P"

Biztos, hogy nem tőlem, mert én eddig mindig azt kérdeztem, hogy minek nekem a ZFS. Egyelőre még keresem, hogy hol lenne jó nekem. Esetleg megemlíthettem, hogy készülőben van egy ilyen lehetőség. Sosem recskáztam a ZFS-re. Keversz valakivel.

"Ha jobban meggondolom, ez a Linux által jelenleg normálisan támogatott fájlrendszerekre nézve kurva nagy alázás."

Ezzel nem értek egyet, szerintem a portfólió növelése. A ZFS nem jó mindenhova és nem megváltás mindenkinek. Egy lehetőség lenne a többi közt.

--
trey @ gépház

Hát, erre pro és kontra tudnék dolgokat mondani, de maradjunk annyiban hogy felhasználás kérdése. Aki folyamatosan instabil kernel mellett instabil alkalmazásokat használ az meg is érdemli. Stabil kernel/alkalmazások mellett egyenlő esélyekkel indul mind a kettő (Win/Lin).
(gyk: a windowson persze nem értelmezett az instabil kernel fogalma).

Az én tapasztalataim pontosan ellentétesek (XP nem bírja lekezelni azt, ha egy indítás után 50x dvd-t cserélek, bezavarodik (értsd: 15 percig nem válaszol az explorer.exe, msn, msoffice és egyéb ms alkalmazások, a firefox is csak úgy araszolgat), ha wlan és lan hálózat között akarok váltogatni, és __marha lassú__; ezzel ellentétben a Linux alatt wlan és lan közti váltás tökéletesen megy, észre sem lehet venni, és érezhetően gyorsabb, mint az XP). De fogjuk rá, hogy WORKSFORME(tm).

---------
WARNING: Linux requires you to type! After rebooted to Windows, you can safely unplug your keyboard.
szerény blogom -- új címen!

A DVD-s probléma két gépen jelentkezett. Az egyiken volt SP1 és SP2 is (kb 4 éve van meg ez a problémám), a másikon csak SP2 volt eddig. Linux alatt nem volt jelen (pedig ott is párszor átpörgettem a kb 70 lemezből álló DVD archívumot, mert kerestem valamit). A wlan dolog Linux alatt nem jelentkezik.

---------
WARNING: Linux requires you to type! After rebooted to Windows, you can safely unplug your keyboard.
szerény blogom -- új címen!

"A pokolba vezetô út is jó szándékkal van kikövezve ..."

Ahogy látom, minimum a karakterkódolással problémáid vannak. De ne add fel, 2007 végére csak tudsz majd írni normális "Őő" betűket, ha már nekem is sikerült Linux alatt.

--
trey @ gépház

apropo, ilyen karakterzsenik jottek itt ossze, akkor lenne egy kerdesem:
hogyan allitom be az xorg.conf-ba, hogy us _es_ hu qwerty kiosztas legyen?
panel pluginnel valtanek kozottuk, de ez a ket kiosztas sehogy sem ment eddig :(

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

Option "XkbLayout" "us, hu"

de, ha adok neki egy ilyet:

Option "XkbVariant" "qwerty"

akkor nem mukodik :P
ha csak hu van akkor igen...

Az X11 teljesen alkalmas desktop funkciokra, a vak is lathatja ;)

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

Hatja, az oke hogy a linuzos mit csinal a tobbtiz giganyi doksijaval? gzippeli aztan zless, zgcc, zvi, etc

OSX-en viszont van Spotlight, ami ugye nyilvan megint egy mestersegesen generalt igeny es felesleges szolgaltatas (foleg notebookon persze;)), ennek ellenere en naponta hasznat veszem (most a mediocre floss utanzatokat hagyjuk).

Szó sem volt az OSX-ről, ne keverd bele. Tudjuk, hogy OSXISBETTER(tm), de nincsen pénzem makkra. Marad a trágya-PC, meg hozzá a kevésbé-trágya-desktopra-is-alkalmas-OS (Linux).

---------
WARNING: Linux requires you to type! After rebooted to Windows, you can safely unplug your keyboard.
szerény blogom -- új címen!