A JMS 578 megfelelő chip, az elvileg támogatja az UASP módot, TRIM-et, és SMART-tot is. Nekem is van egy, igaz a SMART talán nem megy, de a TRIM és az UASP mód igen. De rég próbáltam, lehet minden menne ma már vele.

Az fstrim-nek ez a működése. Ha újrabootol a rendszer, akkor a felcsatolt partíciókon az egész szabad helyet végig TRIM-ezi (vagyis nem teszi, csak kiküldi a TRIM parancsot ezekre a szektorokra az SSD vezérlője felé). Viszont ha nem bootolsz újra, akkor második-harmadik, stb. futásnál megjegyzi, és nem TRIM-ezi meg az egész üres szabad helyet, hanem csak azokat a szektorokat, amik a legutolsó fstrim futása után szabadultak fel.

Sziasztok

ffmpeg-el szeretnek upscale-elni egy videot, de nem tudom ravenni a GPU-t, h besegitsen. 
OS: Manjaro KDE
GPU: RX 5700
CPU: 3300x
Ezeket probaltam:

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i CONVERT.mp4 -vf scale=2560x1440:flags=lanczos -c:v libx264 -preset slow -crf 21 VIDEO.mp4

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i CONVERT.mp4 -vf scale=3840:2160:flags=neighbor -c:v libx264 -profile high -preset slow -rc vbr_2pass -qmin 17 -qmax 22 -2pass 1 -c:a:0 copy -b:a 384k VIDEO.mp4

ffmpeg -i CONVERT.mp4 -vf scale=3840:2160:flags=neighbor -c:v h264_amf -profile high -preset slow -rc vbr_2pass -qmin 17 -qmax 22 -2pass 1 -c:a:0 copy -b:a 384k VIDEO.mp4

Egyik sem hasznlaja a GPU-t, a CPU viszont 100%-on teker.

Mit rontok el ?

Segitseget elore is koszonom.

libva-mesa-driver fent van? Más alkalmazásokban megy a hardveres dekódolás?

fent van. kdenlive alatt megy rendesen, es vainfo alapjan is minden jo.
Kozben probaltam a kovetkezovel:
ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -vaapi_device /dev/dri/renderD128 -i INPUT -c:v h264_vaapi -profile:v high -level 41 -vf "format=nv12|vaapi,hwupload,scale_vaapi=w=2560:h=1440:format=nv12" -c:a copy OUTPUT

De ezt kapom vissza:
[h264_vaapi @ 0x55b7251877c0] No quality level set; using default (20)
[h264_vaapi @ 0x55b7251877c0] Driver does not support some wanted packed headers (wanted 0xd, found 0)
[h264_vaapi @ 0x55b7251877c0] Driver does not support packed sequence headers, but a global header is requested.
[h264_vaapi @ 0x55b7251877c0] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).
Could not write header for output file #0 (incorrect codec parameters ?): Invalid data found when processing input
Error initializing output stream 0:0 --
Conversion failed!

[ Szerkesztve ]

Milyen GPU-ról van szó? Biztosan támogatja x264-ből az 1440p-t?

rx 5700

Szerintem meg van a beallitas vegre, ezzel a cpu pihen, gpu dolgozik:

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i CONVERT.mp4 -vf 'scale_vaapi=w=2560:h=-2:format=nv12' -c:v h264_vaapi -qp 18 -c:a copy VIDEO.mp4

Bar igy is kapok, par fura dolgot:
Driver does not support some wanted packed headers (wanted 0xd, found 0).
Driver does not support packed sequence headers, but a global header is requested.

No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).

Örülök, hogy meglett. Ennek alapján az volt a baj, hogy az először megadott -profile:v high -level 41 profil nem tetszett a hardveres enkódernek, míg a -qp 18-at elfogadja. De ez is csak erős tipp.

Nagyon ugy nez ki.
Kozsonom a segitseget.

csak hogy meglegyen a follow-up...

egyszerű LVM kötetbe volt szervezve 5 db 2TB-os HDD-m.
pár óránként jött a dmesg-be a fentihez hasonló üzenet, hogy most az ata5 esett le egy pillanatra, aztán az ata6, stb, de egy másodpercen belül már újra elérhető volt.
aztán egyik nap eltűnt 4TB-nyi adat, ezen felbuzdulva úgy láttam, hogy igazad volt*, és ez így nem mehet tovább, viszont gyanús volt, hogy egyébként a lemezek jók, a hiba máshol lesz.
lementettem mindent a kötetről, és az egészet átszerveztem egy ZFS kötetté, egész pontosan RAIDZ1-é (ami kb RAID5-nek feleltethető meg, egy lemez kiesését tolerálja). Azóta egyetlen esetben sem jött elő a fenti hibaüzenet.
úgy gondolom, hogy a SATA vezérlő nem tudott valamit elég gyorsan és / vagy jól csinálni, amire az LVM-nek igénye volt, aztán időnként feladta, és eldobta a lemezt, a ZFS meg talán hatékonyabb és nem fut bele ugyanabba a korlátba.

* a torrentkliens webfelülete nem volt lejelszavazva, szerintem ott jött be valaki vagy valami, és egyszerűen kitörölte amit talált, mert kizárólag a seedben lévő dolgok tűntek el minden hibaüzenet nélkül.

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

RAIDZ-nél vigyázz, mert sokkal kényesebb a memória hibákra. Nekem ECC RAM-ok vannak a microserverben szóval nem aggódom emiatt.

⭐ Stella

van ecc-s notebook ram, de nincs rá szükség.
az ecc-s ram annyival jobb, mint a sima ram, hogy egy bit hibát ki tud javítani. de nem ez számít, hanem az, hogy történhet-e memória hiba detektálatlanul, és az a sima ramnál sem fordulhat elő.

a seedben levő dolgok úgy is el tudnak tűnni, hogy a torrent kliensben be van állítva, hogy unregistered torrentet töröljön az adatfájlokkal együtt és a trackeren kitörlik a torrentet.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Lehet, de egyrészt ilyen nem volt beállítva, másrészt igen valószínűtlen hogy pont azt a 600+ torrentet töröljék, ami nálam seedben volt.

Igazából ez lett gyanús, miután sehol nem volt semmi hibaüzenet vagy napló, ami nyomra vezetett volna, hogy hová lettek az adatok és miért pont az tűnt el, ami.
Beléptem a torrentbe és az tűnt fel hogy nem az van hogy 600-szor ki van írva hogy "missing files", hanem hogy tök üres az egész... 0 betöltött torrent.

[ Szerkesztve ]

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Egyetértek. Erről szoftveres rétegben kéne gondoskodni, hogy az ellenőrző-összeg nyilván legyenek tartva, meg összehasonlítva eltárolásnál.

A DDR5 állítólag megszünteti ezt a mizériát, mert abból csak ECC-s lesz, még desktopon is. Megszüntetik ezt a kettős vonalat.

De elvileg a DDR4 vezérlésében már most is vannak olyan elemek, amik valamilyen szintű hibajavításról gondoskodnak, ettől még a non ECC DDR4 RAM nem lesz ECC-s, azt teljesen nem váltja ki, de a semminél jobb.

Egyébként mióta PC-zek, kb. 32 éve, nekem sose volt ilyen bitflip hibám. Volt olyan, hogy a RAM vagy az alaplap volt teljes kaka, akkor sem bitflip volt, hanem azonnal fagyott az egész OS-estől, vagy be sem bootolt, olyan szinten volt hibás. Vagy HDD lett bad sectoros, vagy áramszünet miatt sérült az adatintegritás. De bitflipből még sose lett gondom. Amikor meg nagyon ritkán mégis előfordul valakivel, annak a kivédésére jók a szoftveres megoldások. Ez az ECC-mánia túl van spilázva. Ilyen szintű biztonság max. bankoknál, hadseregnél, CIA-nél, stb. indokolt.

[ Szerkesztve ]

Akkor az én otthoni NAS-om CIA szintű.

⭐ Stella

"de nem ez számít, hanem az, hogy történhet-e memória hiba detektálatlanul, és az a sima ramnál sem fordulhat elő."

Ez jó, akkor kukázom a memtest-et, nem is értem a sok hülye miért futtatja mindig. Azt se vágom miért hangsúlyozza mindenki, hogy használjunk ECC memóriát ZFS-hez. Én is csak pár bejegyzést olvastam arról, hogy valakinek teljes adatvesztése volt belőle. Kicsi a kockázat.

Amennyire én tudom az ECC is csak single bit flip ellen véd, esetleg 2 bit flip ellen, de 3-nál már az is csődöt mond. Wikipedia szerint row hammer-nél volt már példa 3-as flipre, amit nem detektált.

[ Szerkesztve ]

Buliban hasznos! =]

> De bitflipből még sose lett gondom. Amikor meg nagyon ritkán mégis előfordul valakivel, annak a kivédésére jók a szoftveres megoldások.

Aha, szoval amikor a program allokal egy tombot, akkor meg csinaljon ra CRC-t is?

while (!sleep) sheep++;

sziasztok

Hogy lehet kideríteni mi, és miért használja valami a 2-ből egyik cpu magot szinte folyamatosan (néhány másodpercre visszaesik a használat, majd újra 50% sok másodpercig, néha 75 is), és a top-ban nem látszik?

hitler, sztálin, micro usb

a ZFS ezt is megoldotta

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

történhet-e memória hiba detektálatlanul, és az a sima ramnál sem fordulhat elő

De, bőven előfordulhat.

(#30366) Frawly

Erről szoftveres rétegben kéne gondoskodni, hogy az ellenőrző-összeg nyilván legyenek tartva, meg összehasonlítva eltárolásnál. Erről nem tudsz a szoftveres rétegben gondoskodni. Bőven fut olyan kód a rendszeren, amihez nem lehet plusz ellenőrzést rakni (pl. egy interrupt handler a kernelben).

Egyébként mióta PC-zek, kb. 32 éve, nekem sose volt ilyen bitflip hibám. Volt olyan, hogy a RAM vagy az alaplap volt teljes kaka, akkor sem bitflip volt, hanem azonnal fagyott az egész OS-estől, vagy be sem bootolt, olyan szinten volt hibás. Volt bőven, csak nem tudsz róla

(#30368) inf3rno Nagyon ritkán előfordulhat, hogy nem detektál egy több bites hibát, de ennek az esélye minimális. Ha unrecoverable error van akkor meg jön a fatal machine check és a kernel pánik.

Igen, ha mission critical, akkor csináljon. Tudom agyrém, de ha valaki paranoiás, akkor megéri vele szenvedni. Mondom, a legtöbben túllihegik ezt a kérdést.

Ez a használjatok ECC-t ehhez-ahhoz jellegű szlogen, csak ajánlás.

Igen, de ha nem tudok róla, meg nem volt belőle adatvesztés, akkor miért számítana? Általában egy RAM vagy jól működik, vagy nem. Utóbbi esetben sokkal durvább jelei vannak, mint a bitflip. Ha meg működik, akkor meg a bitflipnek nincs gyakorlati jelentősége, annyira ritka.

Nem ajánlás, mert ténylegesen vezethet adatvesztéshez, ha hibás memória marad a rendszerben valahogyan. Indulásnál volt már, hogy átment a memória teszten nekem rossz memória. Utána csak az OS tudja megfogni, de ahhoz azt hiszem az kellene, hogy kernelt vagy ilyesmit töltsön rá, amit ténylegesen ellenőriz. Ha sima fájlok mennek bele pl másolásnál, akkor a másolat köszönőviszonyban sem lesz az eredeti fájllal. A ZFS-nél még ott van az automatikus javítás, amit azt csinálja, hogy checksumot ellenőriz, aztán felülírja a hibás blokkot a jóval. Itt is kaphatsz hibás checksumot egy blokkra, aztán ha talál jó checksumosat, akkor felülírja a blokkodat ugyanúgy szeméttel. Ami miatt redundanciát vesztesz. Elvileg van valami threshold, hogy egy lemezen mennyi hibás checksum lehet, de gondolom jó magas, úgyhogy el tudsz lenni redundancia nélkül egy jó darabig. Meg írhatod ugyanúgy a hibás backupokat is egy másik lemezre. Aztán amikor elszáll a lemezed, ami az egyetlen jó másolatot tárolta az adatról, akkor csak pislogsz, hogy mi van. Nyilván ehhez az kell, hogy ne vedd észre egy darabig, hogy nyüzsögnek a checksum errorok, és valami gond van. Azt nem tudom, hogy az egyetlen jó checksumos blokkot is felül tudja e írni hibás memória miatt. Erre a triviális mód egy checksum collision lenne. ZFS alapból fletcher2-t használ, amiről kb. semmit nem tudok, de valszeg messze nem collision mentes. Át lehet állítani, hogy sha-256-ot használjon, azzal biztosan nem írja felül a jót, de jóval lassabb lesz. Ezen felül viszont nem ismerem eléggé a fájlrendszer felépítését, hogy tudjam máshol milyen károkat okozhat a hibás memória. Elvileg minden blokk felett van valami szülő blokk, ami tárolja a checksumot hozzá, és legfelül van valami über block, amiről több másolat készül. Ha az über block és a másolatai átírásra kerülnek, akkor az egészet lehet kukázni jó eséllyel. Szóval szerintem valós veszélyt jelenthet a nem ECC memória. De nagyjából annyi a tudásom a témáról. Valaki biztos meg tudja magyarázni, hogy megéri a kockázatot az olcsóbb alaplap és processzor, ami nem támogatja az ECC-t, mert az adatok amúgy sem érnek annyit.

[ Szerkesztve ]

Buliban hasznos! =]

Simán képes "összefirkálni" a fájlrendszert amikor kiíródik a page cache. Nem véletlen, hogy minden szerverben és kritikus rendszerben ECC ram van. Arról nem is beszélve, hogy a kernel képes lapokat hibásnak jelölni, így hibás RAM esetén is biztosítható a folyamatos működés.

De milyen adatvesztéshez? Tegye már fel itt a kezét, aki bitflip miatt vesztett adatot. Mondom kizárólag bitflip miatt, nem teljesen hibás RAM, bedöglött háttértár, villámkár, kártevő miatt, hanem tényleg csak is kizárólag bitflip miatt. Na, ugye, hogy senki.

Arról nem is beszélve, hogy a tömörített fájlok, médiafájlok (kép, videó, audió), SQL adatbázisok, torrentek, komoly fájlrendszerek (mint a Btrfs, ZFS, és társaik, meg az összes többi fájlrendszer, ami használ tömörítést vagy titkosítást) stb. eleve valamilyen szinten mindig használnak valamiféle CRC megoldást, alapból. Tehát maximum nagyon alap fájlrendszereken lévő plain text fájloknál, és binárisoknál vagy kitéve, hogy a bitflip miatt félremehet valami. De binárisoknál is elméleti az esélye, mert ha egy bit is félremegy, az már másik opcode, azonnal crashel a program, vagy fagy az egész gép, nem marad észrevétlen. Plain text fájlokban, úgy, hogy tömörítve sincsenek, azokban nem tárol senki kritikus fontosságú adatot. Forráskódok általában fent vannak git-en, helyileg pedig megint tömöríteni szokták őket. Így maximum logokról meg CSV fájlokról tudom elképzelni, hogy csak így plain text-ben vannak hagyva, natúron.

Nem bitflipről beszéltem, hanem hibás a memóriáról. A bitflip általában csak bitrotot okoz, pl recsegős lesz egy zene fájl vagy szétmegy néhány pixel egy képfájlon.

[link]
Ez is lehet gond, de nem akkora, mint a hibás memória. Ha a lemezen történik, akkor ha van redundancia a ZFS vissza tudja állítani az eredeti képet. Ha a memóriában történik mielőtt kiírnánk, akkor esetleg backupról lehet visszaállítani, de a változtatások elvesznek, és csinálhatjuk újra. Viszont elég ritka ahhoz, hogy ezzel komolyan számolni kellene. Talán egy emberöltő alatt elvisz 1 napi munkát.
Az oprendszer működésénél szerintem nagyon szerencsétlennek kell lenni, hogy valami komoly hibát okozzon.

[ Szerkesztve ]

Buliban hasznos! =]

Hány ilyet láttam egyszer.

⭐ Stella

Lényegében akkor oprendszer szintjén is értelmetlen a kivédése.

Már minek? A hibás memóriának vagy a bitflipnek? Kicsit is komolyabb helyen szerintem nem megengedhető, hogy csak úgy változzon, hogy mi van a memóriában, azért van ECC. Nem drágább, mint a normál, a CPU és az alaplap a drágább, ami tudja kezelni, de az se vészes. Én workstation lapot és egy Xeont vettem itthonra, teljesen jól megy, és megvoltam kicsivel 100k alatt ezzel a részével. Szerver lappal viszont húzós lett volna az ára, az tény.

[ Szerkesztve ]

Buliban hasznos! =]

Igazából ha megnézem a mostani lapokat már alapnak tűnik, hogy van ECC support. Néhány éve még azt hiszem nem ez volt a jellemző.

Buliban hasznos! =]

Értem, szóval a bitflip még mindig urban legend, mindenki hallott róla, csak még senki nem tapasztalta. Amit a képen mutatsz, olyat én is láttam már, az nem bitflip, hanem okozhatja meghibásodott háttértár, rossz letöltődés. Persze RAM hiba is, de nem bitflip, hanem en bloc kaka RAM. Ezért kell CRC-ről meg redundanciáról gondoskodni, mert nem csak a RAM lehet hibás, meg nem csak bitflip fordulhat elő, önmagában az ECC sem tesz csodát, csak plusz egy védelmi intézkedés a sok közül.

Félre ne értesetek, nem az ECC RAM ellen vagyok, ha a platformja támogatja és valaki tud szerezni olcsón (pl. DDR3-ból még olcsóbb is az ECC, mert sok szerverből kukázott RAM-ot árulnak használtan), akkor miért ne, plusz egy védelmi vonal, senkit nem vitt még el a mentő, mert ECC-set használt. Én arról beszélek, hogy ez a divathájp, meg tömegpánik, hogy ZFS, jajjaisntem, csak-ECC, jajjmerhamivanhabitflipvanezeréventeegyszer hiszti csak ilyen marketingesek által felfújt baromság. Nem szabad neki bedőlni, van élet az ECC-n túl is.

"van élet az ECC-n túl is." - Üzemeltetsz is zfs-t otthon, vagy professzionális környezetben? (Nem kötekedésből kérdem!)

Nekem itthon is ECC mellett üzemel NexentaStor alatt

⭐ Stella

Talán olvasd el, ami a képhez van írva, "1 bit flipped". Teljesen mindegy, hogy ez HDD, SSD vagy RAM esetében történik, az eredmény ugyanaz lesz. Ha annyira érdekel milyen sűrűn van, akkor keressél tudományos cikket a témában, van egy jó pár, ami foglalkozik a gyakoriságával. Ezen kívül a row hammer miatt is erősen ajánlott az ECC, mert annak a többségét is kivédi. Szerintem egyáltalán nem hype, de senki nem kötelez rá, hogy használjad. Megszoktuk már, hogy szeretsz különcködni.

Buliban hasznos! =]

A hype jelen esetben elég vicces, kb. ezer éve minden szerverben ECC ram van. Adatot meg nem tárolunk sem laptopon, sem desktopon.

Igen, ilyen nagyon otthoni üzemeltető vagyok. Mert aztán otthonra végképp kell az ECC meg a ZFS is, feltétlen. Egyszerűen csak azzal otthonos.

Vannak olyan emberek, akik mindent megkérdőjeleznek. Én annak örülök, hogy a chemtrailig meg a gyíkemberig még nem jutottunk el.

Buliban hasznos! =]

Az alábbi két NFTABLES szabály között mi a különbség? A "meta" kulcsszót milyen esetekben kell, illetve érdemes használni? Köszi annak aki tud segíteni!

meta l4proto tcp ct state new tcp dport 22 counter accept
tcp ct state new tcp dport 22 counter accept

[ Szerkesztve ]

''A szíved szabad! Légy bátor és kövesd!''

itt nem sok, mindkét esetben ugyanazt az expressiont kapod. meta-val a csomag meta adataira lehet matchelni, olyanra is amivel a payloaddal nem biztos. pl interface tipusa, neve, vagy cgroup...
(egyébként a másodiknak mintha hiányozni az eleje)

Lehet hiányos, csak példaként raktam be. Engem most csak a meta kulcsszó működése érdekel az nftables esetében.
Szóval akkor a lényeg, hogy a meta-val úgy kereshetek, mintha string-ben keresnék agy adott előfordulást? Bár akkor gondolom érdemes a meta kulcszót csak akkor használni, amikor feltétlenül szükséges, mert lassabb lesz az adott szabály feldolgozása, mintha csak a payload-ban lévő adatokra match-elnék?

[ Szerkesztve ]

''A szíved szabad! Légy bátor és kövesd!''

nem, meta-nál is meg van határozva, hogy milyen metaadatra matchelhetsz: [link]

aha, értem. bár az még mindig nem világos, hogy bizonyos kulszavak miért működnek a meta-val és anélkül is. Alább egy példa.

meta iif eth0
iif eth0

''A szíved szabad! Légy bátor és kövesd!''

ott irják a linken:
We have 2 types of meta statement, qualified and unqualified. Qualified ones require you use the meta keyword, and for unqualified ones it can be skipped.

köszi a segítséget, a szokásos szétszórtságom miatt nem vettem ezt észre.

''A szíved szabad! Légy bátor és kövesd!''

át szeretném irányítani egy Pi naplózását a home szerveremre, hogy ez se az SD kártyát koptassa, ha nem muszáj.

amit képtelen vagyok elérni (mert nyilván valami hülyeségen elsiklok), hogy ne ömlesztve vegye át egy fájlba a naplózást a szerver.
mert ugye van a syslog, meg az auth.log, meg a kern.log és társai, de ezek egy fájlba folynak össze a szerveren, holott az lenne az ildomos, hogy ugyanúgy szeparálva jelennének meg, mint a Pi-n.

rsyslog és Debian fut mindkét eszközön

A Pi-n a következő módosult:
az /etc/rsyslog.conf végére biggyesztettem, hogy
*.*   @szerverIpje:514
ebben mondjuk van egy ilyen rész, hogy
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log
és úgy érzem, hogy valahol itt lesz a kutya elásva

A szerveren meg annyi történt, hogy
/etc/rsyslog.d/10-remote.conf
ModLoad imudp
$UDPServerRun 514
$AllowedSender UDP, otthoniAlhálózatom/24
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/.log"
*.* ?RemoteLogs
& ~

most így létrejön egy .log nevű fájl a /var/log/remote/%HOSTNAME% mappában és abba kerül minden

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Üdv!

Történt, hogy a számítógép használatban kevésbé rutinos családtag leformázta a merevlemezét egy véletlen folytán, Windows recovery disk rossz helyre ment ezzel legyalulva a partíciókat és egy FAT32-t hagyott a windows telepítő fájloknak. Kértem, hogy ne írjon rá többet és csatolja le, így nagy adatvesztés a Windows telepítőn kívül nem történhetett. Csak a partíciók vesztek el.

Futtattam rajta egy testdisket, meg is találta a vélhetően hiányzó NTFS partíciót:

A kérdésem az, hogy merjem-e futtatni a testdisket, hátha visszaállítja a partíciókat? Vagy egyenest vegyek egy másik 2 TB HDD-t és photorec-kel próbáljam meg menteni a dolgokat? Csak a képekre lenne szüksége, viszont félek, hogy a partíciók létrehozása csak még több kárt okozna. Tudom, az lenne a legoptimálisabb, ha egy másik HDD-re tükrözném ennek a tartalmát és úgy kisérleteznék, de csak ezért nem akarok beruházni ennyi HDD-be.

Ui.: bocs, ha egy picit off, természetesen Linux alól próbálom helyreállítani a lemezt egyébként...

Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!