Portál AbcLinuxu, 12. května 2025 18:29
ČTENÍ dd bs=1M count=1024 if=test.test of=/dev/null ZÁPIS dd bs=1M count=1024 if=/dev/zero of=test.test conv=fdatasync ROZDĚLENÍ DISKŮ (jednotky = sektory) Disk /dev/sda: 1500.3 GB, 1500300828160 bytes 255 heads, 63 sectors/track, 182401 cylinders, total 2930275055 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x76334c22 Device Boot Start End Blocks Id System /dev/sda1 2048 19531775 9764864 fd Linux raid autodetect /dev/sda2 19531776 2929688575 1455078400 fd Linux raid autodetect ----------------------------------------------------------------------------- Disk /dev/sdb: 2000.4 GB, 2000397852160 bytes 255 heads, 63 sectors/track, 243201 cylinders, total 3907027055 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xd9cd6c6d Device Boot Start End Blocks Id System /dev/sdb1 2048 19531775 9764864 fd Linux raid autodetect /dev/sdb2 19531776 2929688575 1455078400 fd Linux raid autodetect ----------------------------------------------------------------------------- Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00006673 Device Boot Start End Blocks Id System /dev/sdc1 2048 19531775 9764864 fd Linux raid autodetect /dev/sdc2 19531776 2929688575 1455078400 fd Linux raid autodetect ----------------------------------------------------------------------------- Disk /dev/sdd: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0xe27ff672 Device Boot Start End Blocks Id System /dev/sdd1 2048 19531775 9764864 fd Linux raid autodetect /dev/sdd2 19531776 2929688575 1455078400 fd Linux raid autodetect ----------------------------------------------------------------------------- Disk /dev/sde: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0xb765ccd8 Device Boot Start End Blocks Id System /dev/sde1 64 19530608 9765272+ 83 Linux /dev/sde2 19530616 2930277160 1455373272+ 83 LinuxPoslední disk má trochu jiné rozdělení, nicméně to by nemělo vadit, stejné problémy se vyskytovaly i v degradované konfiguraci pole (jen nemám otestovanou rychlost). Zajímavé také je, že resync (právě po přidání tohoto posledního disku) běžel ze začátku 1.5-3MB/s a ráno, když jsem se vzbudil, tak jel 35MB/s... Opět nechápu proč. Dodám ještě, že server není téměř vůbec vytížený, jde vlastně jen o souborový server pro několik uživatelů.
Řešení dotazu:
16.9.2011 18:13
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
Třeba jeden disk "pomalu" umírá - v lepšim případě špatný sektory, v horšim....dělaly mi to zatím dva disky, když se dostanou hlavičky do jednoho konkrétního místa tak disk zacvaká, zastaví se, během chvilky se znova roztočí a snaží se pokračovat...někdy se ani nezastaví a hlavičky jen kmitaj třeba pět minut na jednom místě než se odtrhnou a pokračujou dál (Windows umře hned, tučňák se snaží pokračovat, ale jak se disk chytne tak rychle všechno uložit, protože do minuty příjde kernel panic).
Kupodivu S.M.A.R.T. mi na to říkal že je všechno v pořádku, nakonec mi to jeden člověk pořádně projel, našel DVA špatný sektory a bylo jasno - i když nechápu, brácha má na stejnym disku vadných sektorů údajně desetitisíce a nic jako zastavování nebo ty zátuhy se u něj neprojevuje. Mimochodem byly to disky Western Digital Green, už nikdy víc.
(nic lepšího mě nenapadlo)
Zdá se, že v poli byly dva pomalu umírající disky - jeden víc umírající a jeden míň umírající. Víc umírající jsem vyhodil z pole a proto začal to samé (= vytížení na 100%) dělat druhý, zřejmě míň umírající disk, který byl přecejen trošku rychlejší než více umírající... bohužel mi nedošlo, že v poli můžou být dva vadné disky naráz a proto jsem celou dobu hledal chybu někde jinde, včetně špatného nastavení mdadm a bůhvíčeho ještě :) Díky za nakopnutí. Po vykopnutí z pole i tohoto disku se výkon RAID 1 zlepšil ze 17MB/s na 90MB/s.když jsem to zpozoroval vytížení disku na 100%, zkoušel jsem disk vyřadit z pole a během chvíle začal to samé dělat jiný disk, takže to není tímhle :(
16.9.2011 21:14
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
Pokud jsou to disky WD tak bych se trošku bál, co jsem prostřídal několik WD disků, tak bezproblémově funguje jen historický 40GB, ostatní (dva 500GB) umřely až podezřele rychle, po půlroce jsem jeden posílal na reklamaci, když mi přišel zpátky tak vydržel jen pár dalších měsíců a odešel znova....takže jsem ho poslal na reklamaci (kus za kus) a prodal nový disk jen kousek pod cenou 
Koupil jsem dva samsungy 500GB, systém na RAID0 (až umře disk, tak to poznám), data na kterých moc nezáleží (muzika, panoramatické fotky, výtvory v GIMPu a swap) taky na RAID0 a jen to na čem opravdu záleží mám na RAID1
Snad se moje zkušenost hodila, nikdy bych nevěřil že se disk může zaseknout v jedné pozici a jen tam "tikat" i přes pět minut než se odtrhne a bude pokračovat ve čtení/zápisu.
Proto je dobre pouzivat na tyhle levne sestavy neco kde se o tyhle prusery stara poradne alespon filesystem. Realne je na vyber pouze ZFS nebo Hammer. Btrfs ma do produkce jeste hodne daleko a jeho dostupnot v Ubuntu instalatoru opravdu neznamena, ze se tomu daji sverit data
Taky doporucuju se podivat tady, kde se to popisuje http://openindiana.org/pipermail/openindiana-discuss/2011-August/004914.html
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
