- Magisk
- Akciófigyelő: Jelentősen olcsóbban nyit az Ulefone új mindenese
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy A54 - türelemjáték
- iGO Primo
- Telekom mobilszolgáltatások
- Motorola Moto Tag - nyomom, követ
- Xiaomi Watch S1 - szép az idő
- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
- Vivo X200 Pro - a kétszázát!
-
Mobilarena
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
alitak
senior tag
válasz
Jim Tonic #23048 üzenetére
tömböket töröltem, csináltam újat, telepítettem a rendszert, aztán már nincs boot.
Debian alapú, nem debianra telepítettem, hanem a saját telepítőjét használtam (mint a másik szerverhez is).
FW update-et nem találtam, pedig elvileg van 7es verzió is belőle (most a 6.22.03 van rajta), de ez sem különbözik a másik géptől sajnos :/ -
alitak
senior tag
válasz
Jim Tonic #23046 üzenetére
van, be is van állítva, hogy menjen onnan a boot
mod: alapvetően a raid vezérlő a gond szerintem is, mivel anélkül ment az os. Ezelőtt esxi futott a gépen, ugyanebben a raid összeállításban. Megnéztem a vezérlő beállításait, a Boot support Enabled for BIOS & OS -ra volt rakva. Áttettem OS Only-ra, de így sem indul sajnos.
-
bambano
titán
válasz
Jim Tonic #22975 üzenetére
én már csak olyan régimódi vagyok, hogy az átviteli sebesség csak második a listámon...
semmit nem érsz a nagy átviteli sebességeddel, ha elszáll az egész a rákba...
ezért a privát magánvéleményem az, hogy fontos adatot se linuxos zfs-re, se btrfsre nem teszek.a második privát magánvéleményem az, hogy az adatbáziskezelés alaptörvénye, hogy az adat sok és hajlamos többé válni. ezért háttértárban olyan megoldást választanék, ha több lehetőségem van, ami később bővíthető. tehát kiindulásnak minél kevesebb diszket, darabonként minél nagyobb kapacitással.
a helyedben olvasgatnék a linuxos raid10 driverről is, mert elég érdekes dolgokat művelnek benne...
-
Jester01
veterán
válasz
Jim Tonic #22990 üzenetére
Egy lemezen lévő fájlokból is lehet csak annak nem sok értelme van. Ramdiskből is lehet, de ahhoz meg biztos nincs elég memóriád (de az legalább tuti cpu limites lenne
)
Bármennyire is lassúnak hiszed a procid, azért az mégiscsak egy sandy bridge architektúra az annak megfelelő órajelenkénti utasításciklusokkal ami például veri az én AMD FX-emet. cpubenchmark.net szerint a 847-es single thread 539 pont, míg az FX8350 az 1505 (4GHz-en ugye...) Nem tudom milyen órajeled van szóval az összemérhető kell legyen az én 1.4GHz-re korlátozott procimmal. Memóriától is függ valamelyest de azt megint nem hiszem, hogy sokkal lassabb lenne.
-
-
Jester01
veterán
válasz
Jim Tonic #22985 üzenetére
A lassú rebuildnek ezer oka lehet, például az, hogy lekorlátozzák a sebességét (alapból 100MB/s mostanában a default). Azt hittem volt valami cpu terhelés diagram amit nem vettem észre.
Azért az a sandy bridge celeron nem olyan rossz. De igazából a dolog arról szól, hogy a raid5-nek nincs jelentős plusz terhelése. De ezeket magad is megmérheted illetve mint mondtam a logban is ott az adat a paritásszámítás sebességről.
-
Jester01
veterán
válasz
Jim Tonic #22983 üzenetére
Biztos vak vagyok de nem látom a diagramot amiről beszélsz
Valószínűsítem, hogy az FX8350 erősebb mint a tiéd
de levettem 1400MHz-re és még így is vidáman GB/s nagyságrendű a sebesség vagyis normál 100MB/s körüli terhelésnél (ami úgysem lesz folyamatos) ez kevesebb mint 3% processzorhasználat a paritás számítás miatt. Nyilván egyéb járulékos terhelés lesz, de az minden i/o tetejére rárakódik.
# time dd if=/dev/sdb2 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 7.32325 s, 147 MB/s
real 0m7.326s
user 0m0.005s
sys 0m1.181s
# time dd of=/dev/sdb2 if=/dev/zero bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 8.75018 s, 123 MB/s
real 0m8.753s
user 0m0.004s
sys 0m2.423sUgyanez raid5 esetén (degraded 2 lemez mert nincs több kéznél):
# time dd if=/dev/md7 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 6.86471 s, 156 MB/s
real 0m6.868s
user 0m0.004s
sys 0m1.497sÍrásnál:
# time dd of=/dev/md7 if=/dev/zero bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 7.08272 s, 152 MB/s
real 0m7.086s
user 0m0.005s
sys 0m2.656sLátszik, hogy a sima lemezhez képest nem jelentős a különbség, pedig még kicsit gyorsabb is
-
Jester01
veterán
válasz
Jim Tonic #22978 üzenetére
A rebuild nem a cpu miatt hosszú hanem mert az egész lemezt végig kell nyálazni. 2TB és 100MB/s esetén ez ugye 20000 másodperc ami nem 50-60 hanem 5-6 óra. Processzor terhelést nem tudom hol láttál, de ha már van raid5 támogatás a kerneledben akkor boot logba írja mekkora sebességgel tud paritást számolni. Ez jellemzően több GB/s így normál működés során észrevehetetlen terhelést okoz.
raid5 támogatásom éppen nincs, de a raid6 még bonyolultabb is:
vmunix: raid6: sse2x1 2501 MB/s
vmunix: raid6: sse2x2 3700 MB/s
vmunix: raid6: sse2x4 4502 MB/sA méréshez lekorlátoztam 1400MHz-re a processzoromat
-
F34R
nagyúr
válasz
Jim Tonic #22980 üzenetére
janos666-nak elesben van btrfs raid-je ha jol emlekszem, en is baratkoztam vele, de kicsit macerasabb lenne atmozgatnom mindent. (igen a root fajlrendszert is szeretnem btrfs-nek)
Illetve a gentoo forumon is van egy tag aki SSD-ket rakott raid5-be btrfs fajlrendszeren. -
F34R
nagyúr
válasz
Jim Tonic #22969 üzenetére
raid1, amennyiben bsd-s rendszered van akkor erdemes zfs-ben osszeraknod. zfs-ben talan meg a gentoo a legjobb linux distro, van is livecd-s build belole. hasonlo a btrfs, nem sokat probalt hup-on phoronix-en olvashatsz utanna (szepen feljodik, es ott van a main fs-ek kozt.) talan annyi hogy ehhez friss kernel build-ek szuksegesek.
-
Jester01
veterán
válasz
Jim Tonic #17367 üzenetére
Na jó, de ha amúgy 2-3 perc után rendszeresen elszáll neki a linux, akkor azért a memtest már így is gyanúsan sokáig ment hiba nélkül.
Ettől még lehet hosszabban futtani a memtestet de én megnézném live cd-vel is jelentkezik-e a baj hátha csak valami módon a kernel sérült meg, illetve live cd-ről prime95-öt (mprime) is futtatnék egy darabig.
-
bambano
titán
válasz
Jim Tonic #17356 üzenetére
emlékeimben két opció él, aminek a kikapcsolása után a win-lin kapcsolatok sebessége jelentősen nőtt xp kliens esetén, ez a jelentősen ez negyvenszerestől felfelé. az egyik ez a window scaling, aminek az xp-s implementációja bugos. ezt csak azért írom, mert a bugokat nem tudom windows verziókhoz kötni.
ezen kívül ritka rossz tapasztalataim vannak a path mtu discovery-vel, de ez nálad nem focizik.
nekem se lesz többet gigabyte alaplapom, állandóan rendetlenkedik a sata vezérlője.
-
rt06
veterán
válasz
Jim Tonic #17351 üzenetére
meg egy erdekesseg az elozohoz:
smbget -u cyla -v smb://192.168.0.7/cyla/...1080.mkv
...341.13MB of 6.55GB (5.09%) at 11.37MB/s ETA: 00:09:19igaz ez egyazon vason levo ket virtualis gep kozotti meres
viszont lehet erdemes nem csak a samba oldalan, hanem a windoze-ban is turkalni -
rt06
veterán
válasz
Jim Tonic #17342 üzenetére
feldobod mindket gepre (akar windoze, akar linux), az egyiken inditasz egy szervert (iperf -s), a masikon meg piszkalgatod a klienssel, es nezed, milyen sebesseget produkal (arra ugyelj, hogy a 2-es es 3-as verzio nem mukodik keverve)
pl.:
D:\Programs\iperf2-windows>iperf -c thelma -fM -w4M
------------------------------------------------------------
Client connecting to thelma, TCP port 5001
TCP window size: 4.00 MByte
------------------------------------------------------------
[ 3] local 192.168.0.10 port 59274 connected with 192.168.0.99 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 994 MBytes 99.4 MBytes/sec
virtualis gepre es
D:\Programs\iperf2-windows>iperf -c mir -fM -w4M
------------------------------------------------------------
Client connecting to mir, TCP port 5001
TCP window size: 4.00 MByte
------------------------------------------------------------
[ 3] local 192.168.0.10 port 59317 connected with 192.168.0.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1105 MBytes 111 MBytes/sec
tenyleges vasraemellett nekem is csak 4.5 MBps korul teljesit a samba
kozben nezegettem az smb config-ot, es az alabbiakkal lehet meg probalkozni:
read raw = yes
write raw = yes
#aio read size = 2097152 - ez nalam csak rontot a sebessegen
#aio write size = 2097152
use sendfile = yes -
bambano
titán
-
bambano
titán
válasz
Jim Tonic #17339 üzenetére
hogy a tcp kezelés környékén kell keresni a hibát vagy a sambában.
ha apacsról töltve stabilan hozza a 900 Mbps-t vagy többet, akkor nincsenek alapvető hálózati problémák, hanem sambát kell tuningolni. Ha nem hozza, akkor hálózatot.nem tudom, wines kliensen lehet-e valahogy devnullba letölteni, mert azt nem ártana, hogy ne a helyi diszk fogja meg a mérést.
Új hozzászólás Aktív témák
Hirdetés
- GTA V
- Nintendo Switch 2
- Okos Otthon / Smart Home
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- Xbox Series X|S
- BestBuy topik
- Nyíregyháza és környéke adok-veszek-beszélgetek
- sziku69: Fűzzük össze a szavakat :)
- Magisk
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 5 5500 16/32/64GB RAM RTX 4060 8GB GAMER PC termékbeszámítással
- Honor Pad X8 64GB, Wi-Fi, 1 Év Garanciával
- BESZÁMÍTÁS! HP ZBook 15 G6 munkaállomás - i7 9850H 16GB DDR4 RAM 512GB SSD Quadro T2000 4GB WIN10
- Keresem : Lenovo Legion 5 16IRX9 83DG0037HV
- Samsung Galaxy A14 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged