ps.: Az egyeduli ilyen kesleltetett iras modot ugye a writeback-et ismerem. De multkor ezt hasznaltam, nem volt kimaradas, ingadozas, minden stabilan futott. Sync-eltem is leallitas elott. S igy se tudott betolteni valamit es beallt boot. De lehet itt mas gond is volt, passz.
- honorshark blogja
- A hozzászóláshoz be kell jelentkezni
- 1761 megtekintés
Hozzászólások
A torrent kliens részéhez nem értek, de a merevlemez akusztikus szintjét be tudod állítani minimálisra, így nem lesz hangos, és nem melegedik annyira, a teljesítmény így is elég lesz letöltéshez.
Én Transmission-t használtam, optimalizált XFS fájlrendszerrel, külső WD Caviar Black merevlemezzel (minimális hangerő és teljesítmény beállítással) és nem voltak ilyen gondjaim.
- A hozzászóláshoz be kell jelentkezni
A következők kellenek - időről időre xfs_fsr -v /dev/sdXX, éjszakai cronba pedig "nice -n +19 ionice -c3 xfs_fsr /dev/balvg/downloads" szerűség.
EXT* torrentezésre felejtős.
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Akkor miért erőlködsz?
18 gigás file eltávolítása (time rm):
ext3 - 27.7 s
reiserfs - 8.5 s
ext4 - 2.8 s
xfs - 0.193 s
Esetleg megnézheted a fájl generálás fragmentációval és anélkül eredményét is.
-n fájl mennyisége -s egy fájl mérete (KB-ban)
ulimit -a értékét előtte megnézni, ne legyen meglepetés.
1. N fájl írása M KB-ként megadott helyre "nyítás - M KB írása - lezárás"
2. N fájl írása M KB-ként "1 fájl megnyítása, 1 KB írása, 1-es fájl lezárása, 2-es fájl megnyitása..."
3. N fájl írása M KB-ként "N fájl megnyítása, 1-es fájlba 1 KB írása, 1 KB beírása 2-es fájlba..."
Plusz, nagyon sok linuxos torrentező van (több mint a hupon) torrents.ru-n, nekik, tapasztalatuknak, tesztjeiknek valós mindennapos felhasználás során valahogy jobban hiszek ilyen jellegű kérdésben.
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/
- A hozzászóláshoz be kell jelentkezni
szerintem Te erőlködsz, nekem tökéletesen megfelel az EXT3/4 a torrentes gépemen, minden hiba nélkül...
kicsit sem érdekel, hogy mennyi egy fájl törlési ideje...
--
by Mikul@s
- A hozzászóláshoz be kell jelentkezni
Tehat XFS... jolvan. :) (A HUP-os WIKI-ben levo "mount/mkfs" opciok jok lesznek?)
- A hozzászóláshoz be kell jelentkezni
Szia!
Én írtam a wikibe, mondjuk lognak 256 megát adtam meg és úgy használom. :)
Torrenthez annyit mondanék, hogy mostanában tesztelgettem jó néhány torrent klienst XFS alatt és patchelés nélkül egyedül az általam is eddig került Vuze volt képes töredezettség nélkül tölteni. Hogy ez menjen fent kell lennie az xfsprogs csomagnak (Fedora alatt lehet más a neve), és az Options -> File pontban az "Allocate new files using a method specific to XFS filesystem" opciót kell bekapcsolni.
Töredezettséget pedig ezzel nézheted meg adott fájlra: xfs_bmap -v fájlnév
Transmission kliens elvileg szintén támogatja XFS-t, gyakorlatilag meg marhára nem, 5-6 megás fájlt már kb. 50 részre tördelt. Rtorrenthez meg elvileg van külön patch, de azt még nem néztem meg közelebbről.
Én azt tippelem, hogy magasabb CPU használat és nagyobb hőmérséklet is azért lehetett nálad, mert kismillió extentre tördelődtek a letöltések, mivel a kliens, amit néztél nem támogatta az XFS-t. Amúgy meg iszonyat lassú egy ilyen több száz, esetleg ezer részre tördelt több gigás fájlt töredezettségmentesíteni, legalábbis nálam, így inkább használom a Java-s Vuze-t, cserébe semmivel sem növeli a torrentezés a töredezettséget. CPU használatát meg értelmes szintre le lehet vinni, ha jól beállítja az ember, memória használata az sok, de nálam amúgy is kihasználatlan a 4 GB. :)
- A hozzászóláshoz be kell jelentkezni
A log meret mit szamit? Adhatok meg 512m-t is? Vagy a tobb nem mindig jobb?
Jahm meg az lemaradt. Volt egy laptop amin anno filmet neztem. XFS-re formaztam. S ha nem toredezettsegmentesitettem, kepes volt meg a film is beakadni. Ez miert.. ?..(A filmeket FTProl masoltam LAN-on keresztul).
- A hozzászóláshoz be kell jelentkezni
Adni adhatsz, legalább xfsprogs 3.0.3 kell egyébként ahhoz, hogy 128m fölé menj. Egészen 2GB-1 bájtig lehet elmenni elvileg. Nálam kis fájloknál lett gyorsabb 256m-nél, de csak 3-4 mp-es a differencia egy kernelfával végzett fájlműveleteknél, szóval kb. semmi. Szerintem teszteld le a saját adataiddal, illetve azok másolával, törlésével, stb.
Hát nehéz megmondani, hogy mitől akadhatott, le kéne 1x mérni gyengébb gépen egy több száz részre töredezett AVI-val és ugyanannak a töredezettségmentesített változatával. Van 1 tippem, hogy sima másolásnál is töredezhet rendesen. Pl. ha wget-tel töltök valamit az is töredezett lesz, na annyira nem mint torrentnél, de akkor is.
Egyébként a Vuze az xfs_io -c resvp opcióját használja, amivel előre lefoglaltat a letöltendő fájl méretének megfelelő helyet. Talán ilyesmit lenne érdemes FTP-ről átmásolás előtt is csinálni kézzel, de azért ez időigényes szerintem.
Megoldás az lesz, ha rendesen meg lesz valósítva a fallocate() függvény glibc-ben, illetve coreutils is használni fogja ezt. Akkor XFS, ext4, btrfs alatt is rendesen menne az előre lefoglalás. De ez a jövő...
- A hozzászóláshoz be kell jelentkezni
uhh b.sszus.. az a csodas linux. Nem lesz egyszeru menet. Koszonom a leirasokat, magyarazatot. Nemsokara nekiesek.
- A hozzászóláshoz be kell jelentkezni
atom n270 + ubuntu 8.04.3 + laptop vinyó + ext3 + java 1.6 + azureus 2.5.0.4 + "allocate and zero new files upon creation" + jó nagy javavm méret + jó nagy file cache
- A hozzászóláshoz be kell jelentkezni
Én is ext4-re torrentezek, transmission-t használva, ellenben hdd melegedést, és állandó merevlemez kerregtetést nem tapasztalok.
Arch linux-ot használok, az ext4-re vonatkozó bejegyzések az fstabban: nobh,data=writeback,barrier=0,commit=100,noatime
Transmission 1.76 (9395)
A kliens most is megy, a merevlemez hddtemp szerint: Hitachi HDS721616PLA380: 30°C
Több hónapja használom az ext4-et így, volt áramkimaradás, 0 probléma van vele.
---------------------------------------------------------------------------------
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
- A hozzászóláshoz be kell jelentkezni
3.2.4-es ktorrentben van olyan az advanced settingsben, hogy
Reserve disk space before starting a torrent > Fully reserve disk space (avoid fragmentation) > Basic vagy FS specific
:)
---
Tévedni mindenkinek szabad, csak a mérnöknek észre kell vennie.
- A hozzászóláshoz be kell jelentkezni
Koszonom a tippeket. Ext4-es okossagokat felirtam, most XFS van fenn. Tenyleg veszett gyors igy, gyorsabb mint ext4 eddig. Tetszik. :))
- A hozzászóláshoz be kell jelentkezni
Na örülök neki. Még egy kis adalék, hogy talán jobb, hogy nem ext4 mellett döntöttél:
Ext4-gyel volt anno egy kis kalandom, bővebben itt.
Minap néztem a 2.6.32.1-es kernel changelogját, hogy érdemes-e nekem 2.6.32-ről frissítenem, és 3 patch kivételével az összes többi (több mint 2 tucat) az ext4-et foltozgatta. Mondhatjátok, hogy legalább dolgoznak rajta és biztos gyorsabb lett stb., de az "ext4: Avoid data / filesystem corruption..." kezdetű patchleírás nem optimizmusra ad okot.
Egyébként 2.6.33-ban lesz még kis XFS sebesség növekedés, konkrétan 10-15%-os gyorsulást írnak kis fájlok szekvenciális létrehozásánál, lásd itt.
- A hozzászóláshoz be kell jelentkezni
Nekem is volt mar tobb gepen adatvesztesem ext4-el. De hat ha nem akarok adatvesztest akkor maradok a szokasos megoldasnal. LAN-on atnyomom a szerverre ext4-re a mentest, meg utana kozvetlen mentek NTFS-es USB vinyora is. Igy azert mar eleg biztonsagos. (Legfontosabb dolgok meg dropboxon vannak MEG pluszba).
Tetszik egyelore nagyon xfs, remelem mostani palyafutasom jobban sikerul. :)
- A hozzászóláshoz be kell jelentkezni
Lemaradt, hogy ezt találtam még. Hozzátenném, hogy nem próbáltam ki ezt az opciót, mivel nekem egy darab / XFS partícióm van, és ennek szerintem csak nagy fájlokra használt XFS partíción lenne értelme.
- A hozzászóláshoz be kell jelentkezni
A klienshez:
transmission nagyon jó kis kliens, viszont a preallocation-t mindenképpen 2-re kell állítani, különben nagyon töredez. Nekem sima 1-es opcióval egy 4 gigás iso-t képes volt 20000 drarabra cincálni, de 2-essel már csak 7-re egy 80%-ig tele partíción. Tehát 2 mindenképpen!
>>: sys-admin.hu :<<
- A hozzászóláshoz be kell jelentkezni
Hogy az ánuszjáró sün látogatná meg őket hogy nem tudták ezt az opciót a guira kitenni legalább egy advanced options listbe..
mind1, már megtaláltam, csak frusztráló egy desktop appnál ha kézzel kell konfigfájlt szerkeszteni.
Főleg, hogy így eddig nem is tudtam, hogy van erre lehetőség.
- A hozzászóláshoz be kell jelentkezni
A folyamatos irason a noatime es nodiratime(elozo ezt is magaban foglalja) opciok segitenek ahogy irtak a tobbiek.
Meg hozzatennem hogy a sok ram tud sokat segiteni a probleman, foleg xfs-hez.
- A hozzászóláshoz be kell jelentkezni
mennyi ramra gondolsz?
>>: sys-admin.hu :<<
- A hozzászóláshoz be kell jelentkezni
Van 6gb de talan meg bir ha szukseges.
- A hozzászóláshoz be kell jelentkezni
6gb igencsak eleg szerintem
- A hozzászóláshoz be kell jelentkezni
+1 noatime nodirtime az még linus szerint is jóság :)
http://kerneltrap.org/node/14148
- A hozzászóláshoz be kell jelentkezni
Annyi gond akadt hogy Vuze mindenhogyan bugos. Egyszeruen nem tudok kattintani a gombokra, nem nyomodnak be ugy mond, hanem hotkeyekkel kell navigalni ez meg nem tul kenyelmes.
Hogy telepitettem?
- Java felrak (probaltam jre/openjdk6-al is)
- Vuze lekap
- x86_64 SWT lekap
- x86_64 SWT bemasol
- ./vuze
Aztan ennyi.:/
- A hozzászóláshoz be kell jelentkezni
Hmm, és ha 32 bites Javaval próbálnád? Nálam 32 bites a teljes rendszer (Arch Linux), kivéve a kernelt, ami 64 bites, így nem kell szívni a lassabb 64 bites Flash-sel, illetve a csak 32 bites cuccok is futnak mindeféle chrootos gányolás nélkül. Szóval ezen a rendszeren nem volt olyan Vuze bug, amit írtál.
- A hozzászóláshoz be kell jelentkezni
Az a gond semmilyen lib sincs fenn hozza. Most akkor teljes cross rendszert epitsek ki? :/
- A hozzászóláshoz be kell jelentkezni
Én csak azt mondom nézd meg, ha tudod 32 bites rendszeren is, lehet 64 bites java és Vuze nem szereti egymást. Még egy ötlet: állítsd át klasszikus nézetre, hátha... (Tools -> Options -> Interface -> Start -> GUI Chooser)
- A hozzászóláshoz be kell jelentkezni
Ez volt az elso. Az a gond nincs 32bites rendszer se kozel, se tavol. Win-en jo, ennyit tudok. Majd megprobalom 32bites libeket felrakni.
- A hozzászóláshoz be kell jelentkezni
hardy-ban (2.6.24) mennyire (stabilitas, gyorsasag) jo az xfs?
szintet transmissionra kell, az nembaj ha elszall az adat, majd letoltom megegyszer, csak stabil legyen a cucc.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Az nem mai darab. :) Szerintem korrekt mkfs és mount opciókkal nem kéne sokkal lassabbnak lennie mint mostani kernelekkel. Bár rémlik, hogy cfq IO-ütemezővel korábban számottevően lassabb volt, és akkoriban a deadline ütemezőt ajánlották, de azt most meg nem mondom, hogy .24-re igaz-e ez. Ki kell próbálnod, akkor kiderül. :)
Illetve, a HupWiki-s mount opcióknál leírtakhoz biztos, ami biztos alapon hozzátenném még esetedben a logbufs=8 opciót is, ami már egy ideje alapértelmezett, de régebben nem volt az és ez is teljesítménynövelő.
- A hozzászóláshoz be kell jelentkezni
a teljesitmeny nemis annyira fontos, inkabb hogy stabil legyen (ugy ertem nefossa ossze magat a kernel egy bugtol: nem orulnek, ha azert nemtudom elerni az otthoni gepem, mert a router elpanicolt...)
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Hasznaltam joideig XFS-t, problemat egyszer sem tapasztaltam. (Igen az emlitett kernel idejen hasznaltam fokent mert a mondott laptopon is 8.04 volt. Csak annyi ugye hogy nem volt 'finomra-hangolva'. S ugy tenyleg kegyetlen tud lenni.)
- A hozzászóláshoz be kell jelentkezni