UHU 1.1.1 és lassú hdd elérés

UHU Linux

UHU 1.1.1 és lassú hdd elérés

  • 1061 megtekintés

( vmiklos | 2004. 06. 08., k – 10:19 )

[quote:aaebeecff0="mrbond"]
a másik meg a supermount. ezt lecseréltem subfsre

az uhuban a / is supermounttal van csatolva :?: :?

( pete | 2004. 06. 10., cs – 23:58 )

~20 Mb, de szimatolok valamit... nem volt 2x600 mb hely de átvettem a /root-ba egy CDnyi cuccot, ~ 600 megát. elkezdtem a /root/temp-be másolni, elvileg nem volt annyi hely, amennyi kellett volna de nem volt hibaüzenet, fájlméret stimmel. ?

PS: a levél elment a dev listára, lélegzet-visszafolytva várom a fejleményeket.

( pete | 2004. 07. 19., h – 18:07 )

Ne legyen ebből flame pls.!

Pozsy: kösz hogy tételesen foglalkoztál a problémámmal, de én már egy hónapja lezártam. Nem tudom mi lehet a probléma oka (ha szar a fat32 support, akkor hogy mehet máshol rendesen?). Tökmindegy.

Reményem a megváltásra a 2.6-os kernelszériában és az UHU 1.2-final-ban van.

( pete | 2004. 06. 12., szo – 15:36 )

Megjött a válasz, nagyon kulturált és segítőkész formában. Összegezve ím most közreadom, mindenki okulására.

dev-request[At)uhulinux.hu írta:
> Tárgy: Re: lassú hdd elérés

> Feladó: Pozsar Balazs <pozsy[At)uhulinux.hu>
> Legjobb tudomasom szerint egyszeruen a linuxos (v)fat driver a lassu,
> igy disztribtol fuggetlenul a problema fennall.
>
> Ha megis tudsz olyan disztribet/kernelt ahol lenyegesen gyorsabb lenne
> mint uhu 1.1 alatt, akkor szolj, es utananezek.
> ------------------------------------------------------------------------

> Feladó: "Janusz (Tamasi Janos)" <janusz[At)uhulinux.hu>

> Tapasztalatom szerint a fat kezelése is, és a hardware is ludas a

> dologban, volt mikor nekem ennél siralmasabb eredményt produkált, de én
> inkább hw-re gyanakszom, mert azért ha nem is 40Mb/s-t de 10-et
> általában szokott tudni, de hozzáteszem hogy nem mindig, nagyon hw
> (alaplap + winyó) függő
>
> pl ugyan azon az alaplapon két különböző winyó teljesen más eredményt
> képes produkáni
> ------------------------------------------------------------------------

> Feladó: Bálint László <balint_laszlo[At)axelero.hu>
> Reszemrol probaltam mar eleg sok disztroval, hardverrel, es neha egesz
> gyorsan indul a masolas,
> de 100 Mb utan garantaltan lelassul. Sokszor orultem volna a 2Mb/s-nek
> is nagyon...
>
> Laci
> ------------------------------------------------------------------------

> Feladó: "Janusz (Tamasi Janos)" <janusz[At)uhulinux.hu>
> igen, általában ez a helyzet, de nekem már sikerült több 100 megát is
> másolni 10MB/s-el FAT-ra, de tény hogy nem ez a jellemző :)
>
> egyébként pedig 900KB/s - 1.5MB/s szokott lenni a sebesség a visszaesés
> után
> ------------------------------------------------------------------------

> Feladó: Toth Marton <retisas[At)retisas.cjb.net>
> A fajlrendszertol fuggetlenul(?) masolasi sebesseget majdnem 2x-esere
> lehet novelni, ha a hatterben elindit az ember egy
> "while true; do sync; sleep 1; done"-t.
> (kulon kabelen levo vinyokrol van szo)
>
> Az oka az, hogy a Linux (2.4-ig, 2.6-ot nem tudom) elobb a memoriaba
> masolja az adatot egeszen addig, ameg be nem telik az erre szant buffer,
> majd ekkor uriti. (ha nem dolgozik a gep, akkor hamarabb is uriti, de
> masolas kozben ez nem mondhato el).
> Vagyis a vinyok lenyegeben felvaltva jarnak.
>
>
> ((BSD alatt ezt sokkkkkkal szebben oldottak meg. Bizom benne, hogy egyszer
> megjelenik az UHU-BSD is:-) ))
>
> Udv.:
> Marci

> Feladó: Toth Marton <retisas[At)retisas.cjb.net>
>
>> A fajlrendszertol fuggetlenul(?) masolasi sebesseget majdnem 2x-esere
>> lehet novelni, ha a hatterben elindit az ember egy
>> "while true; do sync; sleep 1; done"-t.
>> (kulon kabelen levo vinyokrol van szo)
>
>
>> Az oka az, hogy a Linux (2.4-ig, 2.6-ot nem tudom) elobb a memoriaba
>> masolja az adatot egeszen addig, ameg be nem telik az erre szant buffer,
>> majd ekkor uriti. (ha nem dolgozik a gep, akkor hamarabb is uriti, de
>> masolas kozben ez nem mondhato el).
>> Vagyis a vinyok lenyegeben felvaltva jarnak.
>
>
> Ez _nem_ igaz. Abbol, hogy eloszor csak cache-el, nem kovetkezik hogy
> felvaltva tortenne az iras es olvasas, csak annyi, hogy a tenyleges iras
> kesobb kezdodik meg mint a tenyleges olvasas. Ez azonban nagy meretu
> masolasoknal eleve elhanyagolhato, es mivel a user szamara eleve
> transzparensen tortenik, ezert tokeletesen erdektelen, es _NEM_
> befolyasolja a masolasi sebesseget.
>
> Abbol, hogy cache-el, valoban nem kovetkezik (BSD is cach-el, megis jol van
> megcsinalva), viszont _ahogy_ cache-el...
> Ha ket vinyo van egymas alatt egy-egy keretben, es felvaltva eg a lampajuk,
> az azert latvanyos.
> Az igaz, hogy nagggyon pongyolan irtam le az okat, inkabb a konyhanyelv fele
> konvergalva (nemtom mar miert:-)), de a jelenseg letezik.
>
> Ugy nagyon kozelrol nem ismerem a Linux kernelt, de valami olyasmi okot
> sejtek, hogy a sync-eles nem preemptiv (ugy ertem a kernel altal
> kezdemenyezett buffer-kiiras), ebbol mar valoban kovetkezik, hogy nagy fajl
> masolasakor felvaltva dolgoznak a vinyok.
> Ezt meg az is alatamasztja, hogy az eger rangatasara se reagal ez ido alatt,
> de nem neztem utana, lehet, hogy most marhasagot irtam.
>
>>
>>> ((BSD alatt ezt sokkkkkkal szebben oldottak meg.
>>
>>
>> Kivancsi lennek, mire gondolsz.
>
>
> A BSD-s synkerd-re. Csak kb tudom, hogy mit csinal, ugyhogy nem is
> reszletezem, de a tapasztalat az, hogy jobb a hatasfoka.
> Ez egy alacsony prioritassal futo daemon, lenyegeben allandoan "sync-el".
> Az elozo levelben leirt script is ezt akarta imitalni.
>
>>
> Udv.:
> Marci
> ------------------------------------------------------------------------

> Feladó: Tersánszky Csaba <tersanszky[At)linuxforum.hu>
> A Linux Userland File System kernel modul + a captive, eredeti XP
> kernelt és fat drivert használva ezen is segít, nem csak írja az ntfs
> fájlrendszert. Van egy mount.captive-fastfat parancsa, ezzel látványosan
> gyorsul minden fájlművelet. Legálisan birtokolt Dózer XP, v NT kell hozzá.
>
> Most tesztelgetem, az ntfs írási dolgait, ha stabilnak bizonyul bele
> teszem a live 2.1 CD-be.
> ------------------------------------------------------------------------

> Feladó: Christian Hamar <krics[At)linuxforum.hu>
>
>> A Linux Userland File System kernel modul + a captive, eredeti XP
>> kernelt és fat drivert használva ezen is segít, nem csak írja az ntfs
>> fájlrendszert. Van egy mount.captive-fastfat parancsa, ezzel látványosan
>> gyorsul minden fájlművelet.
>> Legálisan birtokolt Dózer XP, v NT kell hozzá.
>>
>> Most tesztelgetem, az ntfs írási dolgait, ha stabilnak bizonyul bele
>> teszem a live 2.1 CD-be.
>
>
>
> Hat akkor ezt ne tedd be a livecd-be, mivel lehet illegalis beletenni ?
>
> Vagy a usert terheli a felelosseg, ha nincs legalis WIndoza ?
>
> Udv
> -krix-
>
>>
>> ------------------------------------------------------------------------

> Feladó: Tersánszky Csaba <tersanszky[At)linuxforum.hu>
> Maga a progi free, csak a user felelőssége hogy a gépén lévő dózer
> legális e, ráadásul szerintem a captive készítője kicsit benne van a
> huncutkodásban, mert ha nem talál a gépen normális dózert, le is tölti a
> ms.-tól a service pack-et, és onnan teszi be a /var/captive alá az nt
> kernelt és fat v ntfs sys-t.
>
> ------------------------------------------------------------------------

( PcZolee v | 2004. 06. 09., sze – 12:40 )

Az UHU csak a CD-Romokat, floppy-t, és az USB-s cuccokat csatolja supermount-al!!! Nézd meg indítás után a mount kimenetét!

( testerlnx | 2004. 07. 18., v – 20:55 )

Melyik levlistre vagy feliratkozva?

( mrbond | 2004. 07. 25., v – 11:22 )

[quote:55f22dd50b="pozsy"][quote:55f22dd50b="mrbond"][quote:55f22dd50b="vmiklos"]imho mrbond kivételesen tévedett :wink:

jaja! sajnos meglehet. már a droidok sem a régiek :twisted:

de akkor vszinű a supermount minden ide sebességéből visszavett egy picit. :(

Ez nem hogy nem valoszinu, de teljesen biztos hogy nincs igy!

Hi Pozsy!
Sajnos ez nem valószínű, hanem biztos... miután kivágtam a supermountot jobb lett a helyzet minden idés téren.
Ja egyébként az uhu 1.0 rcX-ben és a végleges 1.0-ában is ment minden mint a villám a supermountal. az 1.1-re elromlott. itt segített a subfs.

emléxem annak idején még vissza is tettem egy partra az 1.0-át próba végett.
és műxött rendesen. nem volt probléma, hogy honnan-hova másoljak. használok ntfs (read only), fat32, reiser, ext3, ext2 parokat. meg persze van egy dwd+rw-m is idén.
a vas, amin a baglyok repdestek természetesen ugyanaz volt.
sajnos supermountos megoldást nem találtam, ezért átheggesztettem az uhu-t.

Azért további sok sikert kívánok nektek, és kérlek titeket: az uhu 1.2-ben nélkülözzétek az sm-et! : )

( Toma_ | 2004. 07. 27., k – 00:25 )

Udv!

[quote:19219b2b53="Toma_"]
Tegnap masoltam nehany dvd-t (~20GB) mobil rackes FAT32-rol masik FAT32-es particiora, a 20-25 MB/s sebesseggel ment.
(Suse 9, 2.6.5-test5 kernel)
Tény hogy pl. Mandrake eseten, ez masik gepen 2.4.x kernellel 7-10 MB/s.
Sok minden bejatszhat itt, szvsz nehez ugy.
Probald a FAT32-t toredezettsegmentesiteni, es nezd meg ugy is, hogy a masolando anyag meretenek 3 szorosanak megfelelo szabad hely van rajta.

Now:
Tegnap ugyanezzel a ket lemezzel 1.1 UHU-n, supermounttal, 23-26 MB/s volt a sebesseg.

Toma_

( pete | 2004. 07. 18., v – 23:45 )

dev@uhulinux.hu

Most nagyon érdekes dolgok zajlanak ott, megy a pre-pre-pre-beta tesztje az új UHU 1.2-nek.

( pete | 2004. 06. 08., k – 16:10 )

ok, írok a dev-re hátha valaki ...

az alaplap chipset-e nem lehet ludas, mert az asus cusl-2c lapon i812 v. 815 van, a mostanin meg nforce2-ultra :roll:

( mrbond | 2004. 06. 08., k – 16:12 )

[quote:5878a29018="vmiklos"]az uhuban a / is supermounttal van csatolva :?: :?

mert mint gondoltál? a szentlélek adja hozzá? :D na ja.
a hd-k azok statikusan csatolódnak, a penem, meg a cd az subfsből.

[quote:5878a29018="tso"]nem lehet hogy modulból be kellene még tölteni valamit? (esetleg amit az uhu alapból nem vagy rosszul detektált)
kernel forgatásról nem nagyon akarok írni, mert ahogy más fórumokon olvastam uhu alá nem mindenkinek sikerül megfelelő eredménnyel, de esetleg ki kellene próbálnotok más kernellel (ha nem akartok forgatni újat akkor pl 1-2 live cd-vel más-más kernellel)

mondom ezt úgy hogy uhu-t össz-vissz fél óráig próbáltam, ezt a sis chipsetet nem nagyon ismerem...

van saját fordított kernelem: 2.6.4-ck2. semmi gáz vele. qurv@ jó. (igen Vmiki még mindig :D, télleg felvettek már? :twisted:)
ki milyen modulra tippel?
én ezért visszatettem az 1.0-át, hogy hasonlítgassam.
nem találtam semmi különöset. persze a hiba biztos, hogy bennem van.

a legnagyobb probléáma szvsz szerintem akkor is az, hogy az uhu-haladón még csak tippet sem kaptam...

( mrbond | 2004. 07. 27., k – 07:06 )

[quote:93009512f8="Toma_"]Udv!
Now:
Tegnap ugyanezzel a ket lemezzel 1.1 UHU-n, supermounttal, 23-26 MB/s volt a sebesseg.

Toma_

szia Toma. milyen vasad van? milyen kerneled? mid milyen ( nem a hajad színe érdekel). akkor szinte biztos, hogy a bug vas specifikus is. de azt még akkor sem értem, h. 1.0 miért jó, 1.1 meg miért gány?

bár már nem sok értelme van Supermountot hekkelni, mert depracted lett.

na pá

( pete | 2004. 06. 08., k – 16:16 )

hát ez a haladó-dolog gázos. lehet hogy

* senkinek nem tűnt fel a dolog (akkor ovis csoport, nem haladó)
* nem mindenkinél sz@r (de akkor mért nem böffentenek annyit hogy pl. samsung hdd + astalavista1000 chipen nincs ilyen)

:x

( vmiklos | 2004. 06. 08., k – 17:28 )

[quote:0c54edac27="mrbond"][quote:0c54edac27="vmiklos"]az uhuban a / is supermounttal van csatolva :?: :?

mert mint gondoltál? a szentlélek adja hozzá? :D na ja.
a hd-k azok statikusan csatolódnak, a penem, meg a cd az subfsből.

akkor viszont semmi köze az uhusok supermountos gányolásainak _ehhez_ a problémához. nem?

[quote:0c54edac27="mrbond"]
van saját fordított kernelem: 2.6.4-ck2. semmi gáz vele. qurv@ jó. (igen Vmiki még mindig :D, télleg felvettek már? :twisted:)

még nem tudom. de most lesz hétfőn szóbeli. nah, ezt itt nagyon offtotic :?
[quote:0c54edac27="mrbond"]
a legnagyobb probléáma szvsz szerintem akkor is az, hogy az uhu-haladón még csak tippet sem kaptam...

ezt már tudjuk, kb 100x elhangzott már itt a fórumban :twisted:

( mrbond | 2004. 06. 08., k – 17:40 )

bocsi Vmiklos!

félreérthető voltam. eredetile supermountos a /.
nállam már statikusak a hd-k...
bocsi!

( vmiklos | 2004. 06. 09., sze – 21:50 )

[quote:e9b1816180="PcZolee"]Az UHU csak a CD-Romokat, floppy-t, és az USB-s cuccokat csatolja supermount-al!!! Nézd meg indítás után a mount kimenetét!

hm... :?
[quote:e9b1816180="mrbond"]félreérthető voltam. eredetile supermountos a /.
nállam már statikusak a hd-k...

na ezt majd beszéljétek meg :wink:

( pete | 2004. 06. 09., sze – 21:54 )

UHU 1.1.1

[code:1:dea6517153]
pete@petehome:~$ mount
rootfs on / type rootfs (rw)
/dev/root on / type ext3 (rw)
none on /dev type devfs (rw)
none on /proc type proc (rw)
none on /proc/bus/usb type usbdevfs (rw)
/dev/discs/disc0/part3 on /mnt/disk0-Maxtor_6Y080L0-part3 type vfat (rw)
/dev/discs/disc0/part5 on /mnt/disk0-Maxtor_6Y080L0-part5 type vfat (rw)
/dev/discs/disc0/part6 on /mnt/disk0-Maxtor_6Y080L0-part6 type vfat (rw)
/dev/cdroms/cdrom0 on /mnt/cdrom0-TEAC_DV-W58G type supermount (rw,sync,noatime,nosuid,nodev,dev=/dev/cdroms/cdrom0,fs=iso9660:udf:hfsplus:cdfs,tray_lock=onwrite)
/dev/cdroms/cdrom1 on /mnt/cdrom1-TEAC_CD-W552E type supermount (rw,sync,noatime,nosuid,nodev,dev=/dev/cdroms/cdrom1,fs=iso9660:udf:hfsplus:cdfs,tray_lock=onwrite)
/dev/floppy/0 on /mnt/floppy0 type supermount (rw,sync,noatime,nosuid,nodev,dev=/dev/floppy/0,fs=minix:ext2:vfat,tray_lock=onwrite)
[/code:1:dea6517153]

most akkor mi van? :roll:

( vmiklos | 2004. 06. 09., sze – 22:09 )

imho mrbond kivételesen tévedett :wink:

( pozsy v | 2004. 07. 19., h – 10:44 )

[quote:4d89a24315="vmiklos"][quote:4d89a24315="mrbond"]
a másik meg a supermount. ezt lecseréltem subfsre

az uhuban a / is supermounttal van csatolva :?: :?

NEM.

( pozsy v | 2004. 07. 19., h – 10:45 )

[quote:0516888063="pete"]hát ez a haladó-dolog gázos. lehet hogy

* senkinek nem tűnt fel a dolog (akkor ovis csoport, nem haladó)
* nem mindenkinél sz@r (de akkor mért nem böffentenek annyit hogy pl. samsung hdd + astalavista1000 chipen nincs ilyen)

:x

Nyilvan nem mindenkinel ilyen, en pl meg nem talalkoztam vele, pedig sok gepen futtattam mar uhut.

( pozsy v | 2004. 07. 19., h – 10:47 )

[quote:d9675b116e="pete"]ant:
[code:1:d9675b116e]
pete@petehome:~$ df
Filesystem Méret Fogl. Szab. % Csatl. pont
rootfs 4,7G 3,4G 1,2G 76% /
/dev/root 4,7G 3,4G 1,2G 76% /
/dev/discs/disc0/part3
2,4G 2,1G 372M 85% /mnt/disk0-Maxtor_6Y080L0-part3

/dev/discs/disc0/part5
4,8G 2,0G 2,9G 41% /mnt/disk0-Maxtor_6Y080L0-part5

/dev/discs/disc0/part6
65G 55G 9,5G 86% /mnt/disk0-Maxtor_6Y080L0-part6
[/code:1:d9675b116e]
a part3-5-6 fat32 (a winfos miatt, a part3 az 98se boot partíció), a part6-on másolgatam. Win98SE 7-8 Mb/s körül teljesít.

A CPU load felugrik az egekbe (), a scheduler gyorsan le is nice-olja 25-re. Érdekesség:
FAT32 -> FAT32, ugyanaz a partíció 60-80% CPU (mc), 2-3 Mb/s
FAT32 -> FAT32, más partíció *60-80% CPU (mc), 2-3 Mb/s
FAT32-> ext3, 15-20% (mc), 16Mb/s
EXT3 -> EXT3 20-35% (mc), 22 Mb/s
* itt ígéretes 16Mb/s-ről indult, majd ez lett a vége.
A CPU kihasználtság kb 5-10%, ha nincs disk i/o (2500 barton, de a 850-es cerkán se volt sokkal több)

A linux kernel fat drivere lassu es kesz, ezen nincs mit mericskelni, es nem az uhu hibaja.

( pozsy v | 2004. 07. 19., h – 10:48 )

[quote:973ca2c064="mrbond"][quote:973ca2c064="vmiklos"]imho mrbond kivételesen tévedett :wink:

jaja! sajnos meglehet. már a droidok sem a régiek :twisted:

de akkor vszinű a supermount minden ide sebességéből visszavett egy picit. :(

Ez nem hogy nem valoszinu, de teljesen biztos hogy nincs igy!

( Vendor v | 2004. 08. 07., szo – 12:31 )

valaki futott mar bele asus a7a266 (Ali M15x3 Chipset.) es egy seagate 120 gigas winyo hda: error waiting for DMA problemajaba?

uhu 1.1 kamion

uname -a
Linux localhost 2.4.24-7 #1 SMP Wed Jun 16 16:07:17 CEST 2004 i686 unknown unknown UHU-Linux

dpkg -l kernel
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii kernel 2.4.24-12.1 Linux kernel

hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 796 MB in 2.00 seconds = 398.00 MB/sec
Timing buffered disk reads: 10 MB in 3.18 seconds = 3.14 MB/sec

( pozsy v | 2004. 07. 19., h – 10:49 )

[quote:6c676a48b1="vmiklos"]ameddig benne van a kernelben a supermount... :wink:

Hehe, viccesek a megjegyzeseid, es orulok hogy kihasznalsz mindent az uhu fikazasra, de remelem te is tudod hogy nyilvan nem errol van szo.

( pozsy v | 2004. 07. 19., h – 10:51 )

[quote:fea9e84d8f="pete"]na mindjárt megnézem, kivágom a SM-t ... most már télleg érdekel a dolog, baromi bosszantó.

és! kivettem, miután a floppyt meg a CD-DVDolvasókat lecsatoltam. Először szépen elindult 7-8 Mb/s-el (kb. ennyi van win alatt is, stopperrel + isoval mérve) de néhány sec. után (kb mikor a cache megtelt) elkezdett esni és szépen visszaesett 2 megára a végére. az eleje után az ide ledje is csak halványan, fél fénnyel világított = állandó szakaszos i/o, néha fel-fel villant teljesen. a másolás 1 fat32-n belül volt.

Figyi, ha ugyanez mondjuk ext3 vagy tetszoleges normalis filerendszer alatt megy rendesen, akkor egyszeruen csak a fat32 mint filerendszer, illetve a linux fat32 drivere a szar. Marpedig ez a helyzet, igy ezen nincs mit csodalkozni. Lehet valasztani: fat32 vagy sebesseg.

( mrbond | 2004. 06. 10., cs – 05:21 )

[quote:1e04e6a846="vmiklos"]imho mrbond kivételesen tévedett :wink:

jaja! sajnos meglehet. már a droidok sem a régiek :twisted:

de akkor vszinű a supermount minden ide sebességéből visszavett egy picit. :(

( Toma_ | 2004. 07. 19., h – 11:25 )

Udv!

Tegnap masoltam nehany dvd-t (~20GB) mobil rackes FAT32-rol masik FAT32-es particiora, a 20-25 MB/s sebesseggel ment.
(Suse 9, 2.6.5-test5 kernel)
Tény hogy pl. Mandrake eseten, ez masik gepen 2.4.x kernellel 7-10 MB/s.
Sok minden bejatszhat itt, szvsz nehez ugy.
Probald a FAT32-t toredezettsegmentesiteni, es nezd meg ugy is, hogy a masolando anyag meretenek 3 szorosanak megfelelo szabad hely van rajta.

Toma_

( pete | 2004. 06. 08., k – 21:27 )

és a hdd-k statikus mountja segített?

( antiemes | 2004. 06. 08., k – 21:35 )

Hi!

Erdemes lenne egy hdparm -tT /dev/hda (vagy ahol a winyod van) parancsot kiadni. Persze rootkent.

By(t)e
TBS::Antiemes

( vmiklos | 2004. 07. 19., h – 11:40 )

[quote:8969d3c929="pozsy"][quote:8969d3c929="vmiklos"]ameddig benne van a kernelben a supermount... :wink:

Hehe, viccesek a megjegyzeseid, es orulok hogy kihasznalsz mindent az uhu fikazasra, de remelem te is tudod hogy nyilvan nem errol van szo.

nemcsak én, hanem még sokan mások is alapból elutasítják a supermountot, a gányoltsága miatt. pont ezért készült a submount. sztem ti is meggondolhatjátok, h érdemes lenne-e áttérni arra

itt a fórumban is többeknek volt már baja a supermounttal (ld mrbond), amire az általános megoldás a submountra való átállás volt

az 1 másik kérdés, h a debre alapozottsága miatt mi a véleményem a uhuról :wink:
de alaptalanul ritkán szoktam bármit is szidni

( pete | 2004. 06. 08., k – 21:53 )

persze hogy nem akartam szívatni a segítő fórumozókat, megvolt, az
eredmények:

cache read: 758 Mb/s
disk read: 57 Mb/s

off: hogy a francba lehet kimásolni xterm-ből a gnome vágólapjára?

( pete | 2004. 06. 08., k – 22:06 )

bef@sok, kijelöl, aztán középső gomb a dobozba ...

[code:1:ef3ec54f21]
root@petehome:/home/pete# hdparm -tT /dev/hda

/dev/hda:
Timing buffer-cache reads: 1384 MB in 2.00 seconds = 692.00 MB/sec
Timing buffered disk reads: 172 MB in 3.01 seconds = 57.14 MB/sec
root@petehome:/home/pete# hdparm -tT /dev/hda

/dev/hda:
Timing buffer-cache reads: 1472 MB in 2.00 seconds = 736.00 MB/sec
Timing buffered disk reads: 172 MB in 3.01 seconds = 57.14 MB/sec
root@petehome:/home/pete#

[/code:1:ef3ec54f21]

( antiemes | 2004. 06. 09., sze – 01:36 )

Hi!

Hat, akkor nem tudom, hogy mi lehet a problema, de hogy nem a chipsettel van gond, es nem is a winyoval, az tuti. Milyen fs-t hasznalsz? Mennyire van betelve? Volt-e olyan, hogy majdnem tele volt a particio? Uresjaratban mennyi a CPU-kihasznaltsag? Es ha masolsz? Hirtelen ezek jutottak eszembe.

By(t)e
TBS::Antiemes

( vmiklos | 2004. 06. 09., sze – 04:17 )

[quote:fef64b58ae="pete"]és a hdd-k statikus mountja segített?

persze, azóta szidja a supermountot (valljuk be, h jogosan) :D

( pete | 2004. 06. 10., cs – 17:35 )

egy picit? grr... ez azért durva, rákeresek : "supermount speed issue"

( pete | 2004. 06. 10., cs – 17:56 )

hát máshol is sux a supermount. viszont ez még nem magyarázat az alapból helyesen (és statikusan) csatolt hdd-k sebesség-kérdésére.

( vmiklos | 2004. 06. 10., cs – 19:17 )

ameddig benne van a kernelben a supermount... :wink:

( pete | 2004. 06. 09., sze – 09:22 )

ant:
[code:1:b064eabe10]
pete@petehome:~$ df
Filesystem Méret Fogl. Szab. % Csatl. pont
rootfs 4,7G 3,4G 1,2G 76% /
/dev/root 4,7G 3,4G 1,2G 76% /
/dev/discs/disc0/part3
2,4G 2,1G 372M 85% /mnt/disk0-Maxtor_6Y080L0-part3

/dev/discs/disc0/part5
4,8G 2,0G 2,9G 41% /mnt/disk0-Maxtor_6Y080L0-part5

/dev/discs/disc0/part6
65G 55G 9,5G 86% /mnt/disk0-Maxtor_6Y080L0-part6
[/code:1:b064eabe10]
a part3-5-6 fat32 (a winfos miatt, a part3 az 98se boot partíció), a part6-on másolgatam. Win98SE 7-8 Mb/s körül teljesít.

A CPU load felugrik az egekbe (), a scheduler gyorsan le is nice-olja 25-re. Érdekesség:
FAT32 -> FAT32, ugyanaz a partíció 60-80% CPU (mc), 2-3 Mb/s
FAT32 -> FAT32, más partíció *60-80% CPU (mc), 2-3 Mb/s
FAT32-> ext3, 15-20% (mc), 16Mb/s
EXT3 -> EXT3 20-35% (mc), 22 Mb/s
* itt ígéretes 16Mb/s-ről indult, majd ez lett a vége.
A CPU kihasználtság kb 5-10%, ha nincs disk i/o (2500 barton, de a 850-es cerkán se volt sokkal több)

( pete | 2004. 06. 08., k – 06:17 )

Helló mindenkinek,

az UHUval van egy kis baj, nevezetesen az, hogy baromi lassú alatta az ide hdd elérése, a mc 2-3 Mb/sec -et ír ki.

[code:1:a118f014d1]
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 9964/255/63, sectors = 160084415, start = 0
[/code:1:a118f014d1]

maxtor ata133, ugyanezt csinálta egy asus-cusl2c-ben és egy gigabyte amd lapban is
:roll:

( pete | 2004. 06. 10., cs – 21:24 )

na mindjárt megnézem, kivágom a SM-t ... most már télleg érdekel a dolog, baromi bosszantó.

és! kivettem, miután a floppyt meg a CD-DVDolvasókat lecsatoltam. Először szépen elindult 7-8 Mb/s-el (kb. ennyi van win alatt is, stopperrel + isoval mérve) de néhány sec. után (kb mikor a cache megtelt) elkezdett esni és szépen visszaesett 2 megára a végére. az eleje után az ide ledje is csak halványan, fél fénnyel világított = állandó szakaszos i/o, néha fel-fel villant teljesen. a másolás 1 fat32-n belül volt.

( mrbond | 2004. 06. 08., k – 07:30 )

sajnos ez így van. bár nállam a dvdvel volt ue.
2 dolog:
1 az alaplap csipszete a ludas. nekem ez sis630,
a másik meg a supermount. ezt lecseréltem subfsre

unu 1.0 alatt nem volt semmi gond ott ment minden 10-15 MBsel.
írtam az uhu-haladó listára is. magasról sz@rtak a fejemre :(

( tso | 2004. 06. 08., k – 07:45 )

[quote:ea1a3cb237="mrbond"]sajnos ez így van. bár nállam a dvdvel volt ue.
2 dolog:
1 az alaplap csipszete a ludas. nekem ez sis630,
a másik meg a supermount. ezt lecseréltem subfsre

unu 1.0 alatt nem volt semmi gond ott ment minden 10-15 MBsel.
írtam az uhu-haladó listára is. magasról sz@rtak a fejemre :(

nem lehet hogy modulból be kellene még tölteni valamit? (esetleg amit az uhu alapból nem vagy rosszul detektált)
kernel forgatásról nem nagyon akarok írni, mert ahogy más fórumokon olvastam uhu alá nem mindenkinek sikerül megfelelő eredménnyel, de esetleg ki kellene próbálnotok más kernellel (ha nem akartok forgatni újat akkor pl 1-2 live cd-vel más-más kernellel)

mondom ezt úgy hogy uhu-t össz-vissz fél óráig próbáltam, ezt a sis chipsetet nem nagyon ismerem...

( antiemes | 2004. 06. 09., sze – 10:04 )

Hi!

IMHO az 5-10% alapban egy ilyen gepen eleg sok. Nekem Debian alatt 333-as k6-2-n sincs szerintem ennyi. De ez most lenyegtelen...

Gondolom 1 nagy file-t probaltal meg masolni, mert sok kicsinel a noatime opcio is segithet (a mount parametere). Esetleg probald meg defragmentalni a winyot.

Egyebkent a Linux FAT kezeleserol nincs sok tapasztalatom. Nem nagyon hasznalok FAT-ot. Szerintem azt az fs-t nem is fejlesztik olyan aktivan, mint pl. az ext3-at vagy a reisert.

By(t)e
TBS::Antiemes

( uid_1683 | 2004. 06. 09., sze – 10:12 )

A fat32 dog lassu linuxon ennek semmi koze az uhu supermounthoz.
Tanulj meg egyuttelni vele.
Nezd a dolog jo oldalat: itt legalabb elered (ha lassan is) a ma$ fajlrendszert. Ugyanez a tuloldalrol alapbol nem mondhato el :))
Nekem mostanaban tobbszor kellett ntfs particiorol fat32-re masolnom linux alatt es kinott a szakallam, mire atment 22Gb egyikrol a masikra. Kb 4 ora volt es a knoppix meg az uhu azonosan viselkedett mert mindkettovel probaltam.

Laci

( pete | 2004. 06. 09., sze – 10:24 )

az 5-10% csak ~kb volt, az felé nem megy, de ha top-palnézem 95 - 99.7% az idle (disk i/o nélkül :)) )

[quote:115530863a="blaci"]A fat32 dog lassu linuxon ennek semmi koze az uhu supermounthoz.
Tanulj meg egyuttelni vele.

dehogyis, egy szabad estén elküldöm a halál f...-ra. Mivel ez rendszerhdd, tehát más win sose látja, felrakok egy ext3-at. Win alá van ext2-3 olvasó :)

kösz a helpet, mindenkinek!

( pete | 2004. 08. 08., v – 22:48 )

nekem hasonló volt egy másik, dev kiadású UHU-val, de elmúlt (néhány release után)