Dotaz: Dell Poweredge III 2950 a GPT/BTRFS

[MP]

Hoj,

mam na jednom HP serveru 4 disky. 2 jsou MBR (mdadm+btrfs oddily), 2 jsou GPT (btrfs oddily). Jsou pripojene primo pres sata. Tvori to tak mdadm raid1 a btrfs raid10. Kdyz tyto disky prehodim do aktualizovaneho Dellu (raid0 virtual device pro kazdy disk pres Perc 6i), tak ty dva disky s MBR jsou ok. Btrfs oddily na MBR discich jsou ok, na GPT discich ale "btrfs device scan /dev/sdxy" havaruje s hlaskou, ze "error not a block device", takze cele btrfs pole je kaput. Otazkou je, zda je to problem podpory GPT v radici/dellu, nebo nekde jinde? Netusi nekdo?

Odpovědi

[trubicoid2]

"btrfs device scan /dev/sdxy" je co? to je hlaska initramfs?

system je na tom gpt a nenabehne? nebo na mbr a nabehne? pak by se dalo podivat na ty gpt disky a namountovat pole rucne

pokud nenabehne, tak pustit trebas s systemrescuecd

jinak nejak nechapu to madam raid1 a z toho btrfs raid10, to je nejaka velka podivnost, ne?

[Andrej]

jinak nejak nechapu to madam raid1 a z toho btrfs raid10, to je nejaka velka podivnost, ne?

Přesně to mě taky napadlo. Kombinovat mdadm (pseudo-RAID, který by si měl správně říkat „AID“, nikoliv RAID, protože nemá checksumy a nedovede tedy zjistit, která z replik selhala) a Btrfs (kde lze nastavit opravdový RAID) je dost zrádné. Iluze redundance je totiž horší než úplná absence redundance, protože o tom druhém člověk obvykle aspoň ví. RAID10 je nejlepší nastavit pouze a výhradně pomocí Btrfs, bez jakýchkoliv ubohých „AIDů“ bez „R“ (hardwarový (R)AID, mdadm, dmadm), které při silent data corruption nenávratně ztratí data, místo aby před tímto (stále častějším) problémem chránily.

[Jendа]

Někteří lidé preferují nechecksumovaný RAID (kde stejně jsou checksumy v disku, na SATA i v ECC paměti) s hypotetickým rizikem poškození dat, které ještě nikdy nenastalo, před FS s bugy, který jim totálně havaroval už několikrát.

(nejlepší řešení, tedy FS-level RAID s checksumy bez bugů, bohužel momentálně neexistuje -- pokud nepotřebujete změnu velikosti a přidávání disků, tak ZFS)

[Andrej]

Takže, hned na úvod: "Které ještě nikdy nenastalo" je taková kravina, že nad tím zůstává rozum stát. Tak především, silent data corruption je v každém větším úložišti naprosto běžný jev a AID, chybně zvaný RAID, je proti ní naprosto bezmocný, protože nemá checksumy. Postupně a poznenáhlu ztrácí data uživatelů, kteří žijí v iluzi, že ta data chrání (chybějící) redundance.

Ještě důležitější otázka je, proč si někdo (naprosto chybně) myslí, že k poškození dat může dojít jenom v paměti, na disku nebo na SATA. Jako by snad chyba v softwaru nebo (především!) lidská chyba nebyla mnohem pravděpodobnější a častější příčinou problémů. Znám hned několik smutných historek o přepsání jednoho (jednoho!) disku nulami (a nechme stranou, proč někdo takový krok podnikl — zkrátka lidský faktor), které poslalo celý AID5 (chybně zvaný RAID5) do kytek, tedy ztratila se všechna data. Ještě jednou, třikrát podtrhuji: AID5 ztratí všechna data kvůli poškození dat na jednom disku. Co může být horší než tohle? A co teprve AID6 — to je teprve lahůdka! AID6 se dá poslat do kytek přepsáním jednoho disku nulami, nikoliv dvou disků. Slibovaná redundance neexistuje.

Ještě zajímavější paradox: AID1 by měl být teoreticky redundantní, že ano. Takže bez problémů ustojí, když na jedné replice přepíšu všechny bloky nulami? Nebude mi pak doufám náhodně prokládaně číst nulové bloky, že ne? Ouha, bude.

Proti téhle^^^ ubohé iluzi redundance je Btrfs jedno z mála řešení, které dává smysl. Jistě, ZFS je taky možnost a spousta lidí mu dává přednost, protože doufají, že je "stabilnější" (ať už to znamená cokoliv). Nevím, komu kde totálně "zhavaroval" Btrfs, a nehodlám se zabývat anekdotami z roku 2010, historkami o kernelu 3.1 nebo něčím podobným.

[Jendа]

Tak především, silent data corruption je v každém větším úložišti naprosto běžný jev

Pak asi mých několik desítek TB není „každé větší úložiště“.

Jako by snad chyba v softwaru

Například v mnohem komplikovanějším a po 5 letech po označení za stabilní stále neodladěném FS?

nebo (především!) lidská chyba

Jednak si nedokážu moc představit tento typ chyby a jednak btrfs zjevně není odolné proti poškození konzistence a scrub to neodhalí.

Znám hned několik smutných historek o přepsání jednoho (jednoho!) disku nulami

To mdadm nesloží, protože tam prostě nebudou metadata. Že někdo používá shitový HW RAID kterému se tohle stane je jeho problém.

Nevím, komu kde totálně "zhavaroval" Btrfs, a nehodlám se zabývat anekdotami z roku 2010, historkami o kernelu 3.1 nebo něčím podobným.

Mně, šlo o kernely 3.19 a 4.4, a bylo to v letech 2015-2017.

[Andrej]

Pak asi mých několik desítek TB není „každé větší úložiště“.

Ne, tvé desítky TB nejsou větší úložiště. Větší úložiště mají PB, případně (bavíme-li se o větších "internetových" firmách) EB.

Například v mnohem komplikovanějším a po 5 letech po označení za stabilní stále neodladěném FS?

Tahle údajná neodladěnost je slovíčkaření. Není jasná definice takového pojmu. Ext4 měl v nedávné době několik zásadních bugů spojených se ztrátou dat, ale pořád se najdou exoti, kteří řeknou, že Ext4 je "odladěný", zatímco Btrfs ne. Takové označování prostě nedává smysl.

Jednak si nedokážu moc představit tento typ chyby a jednak btrfs zjevně není odolné proti poškození konzistence a scrub to neodhalí.

Ten typ lidské chyby jsem velmi jasně a názorně popsal. Btrfs samozřejmě je odolný proti problémům s konzistencí dat a jejich poškození odhalí. Ten zázrak se jmenuje checksumy. Chyby odhalí nejen scrub, ale i pouhý pokus přečíst poškozená data. To je nakonec nejdůležitější, že Btrfs nevrací poškozená data, na rozdíl například od Ext4, který rád vrací rozsypaný čaj. Takže první část výroku je asi z nepozornosti při četní a druhá část je prostě fakticky špatně.

To mdadm nesloží, protože tam prostě nebudou metadata. Že někdo používá shitový HW RAID kterému se tohle stane je jeho problém.

Zase nesmysly. Zaprvé, disk se nemusí nutně přepsat od začátku. Zadruhé, metadata/superblok nemusí být na začátku; u starších polí bude na konci. Než se disk přepíše, úžasný chytrý AID5 zahájí resilvering. Ani nemusí jít o přepsání namountovaného disku za provozu. Nehoda, kterou jsem zmiňoval, se stala mimo provoz. Disk se přepsal částečně. Metadata na něm samozřejmě zůstala. A pak nastal mount, resilvering a odchod všech dat do věčných lovišť. A vykládej mi, jak to mdadm nesloží.

Mimochodem, proč se dělají crash testy u aut? Když někdo řídí auto, které není bezpečné, je to přece jen a jen jeho problém, ne? Tohle je zvrácená logika. Pokud můžeš mít mnohem lepší zabezpečení dat, bez zhoršení jiných parametrů, neexistuje důvod ho nemít. I kdyby sis nakrásně myslel, že se nikdy nikdo nemůže zmýlit výše popsaným způsobem.

Mně, šlo o kernely 3.19 a 4.4, a bylo to v letech 2015-2017.

Ano, to jsou smutné příhody (hlavně ta na StackExchange), ale například zběžné hledání kritických chyb a ztrát dat v Ext4 vrátí podobných anekdot o poznání víc. Kdybych se měl řídit anekdotami, asi bych nepoužíval žádný filesystém a video bych si kreslil v obrázcích na papír.

[Jendа]

Btrfs samozřejmě je odolný proti problémům s konzistencí dat a jejich poškození odhalí.

Neodhalí, viděl jsem zjevně poškozené filesystémy, které vracely chyby při čtení a scrub proběhl bez chyb.

u starších polí bude na konci

Historky z roku 2010 nás nezajímají ;)

[Andrej]

Btrfs samozřejmě je odolný proti problémům s konzistencí dat a jejich poškození odhalí.

Neodhalí, viděl jsem zjevně poškozené filesystémy, které vracely chyby při čtení a scrub proběhl bez chyb.

Překvapivé. Tak tady by mě upřímně zajímaly odkazy na příslušné bug reporty.

Já jsem zase viděl filesystém, ze kterého jsem sice všechno bez problémů přečetl, ale scrub neproběhl bez chyb. To bylo proto, že odcházel harddisk a jedna z replik metadat už buď nešla přečíst vůbec, nebo na ní neseděly checksumy. (Že to postihlo zrovna kousek replikovaných metadat a nikoliv nereplikovaná data, to byla samozřejmě šťastná náhoda, nic jiného.) Opačný případ jsem ale zatím neviděl.

u starších polí bude na konci

Historky z roku 2010 nás nezajímají ;)

Je obdivuhodné, když někdo všechna svá mdadm pole poctivě kompletně reinicializuje pokaždé, když se změní formát metadat. Ano, s takovou důsledností se pak nemusíš zabývat historkami z roku 2010.

Jinak ta analogie nesedí, protože Btrfs byl v roce 2010 do značné míry experimentální, zatímco mdadm se považuje za stabilní zhruba od třetihor.

[BEDNA]

Silent data corruption je zaklínadlo prodejců předražených storage (h|s)raček. Skoro dvacet let doma počítám tři různé cheksumy každý týden pro každý uložený soubbor na konzumních discích (aktuálně 15TB) na počítačích bez ECC paměti (aktuálně 32GB už 4 roky) s uptimem v řádech měsíců. A hádejte co? NULA silent corruption. V práci těch dat je trošku víc (190TB), servery mají ECC, někde je mdraid, někde jen JBOD a hádejte co? Opět NULA poškozených souborů z důvodu tiché chyby.

[Jendа]

Mám méně dat (~15 TB několik let, MD check a tam kde je btrfs scrub jednou za 1-6 měsíců) a taky 0.

ECC se ale hodí, už jsem jednou hledal podivný bug v aplikaci občas poškozující interní datové struktury, až jsem zjistil, že data poškozuje RAM.

[Peter Golis]

Ja som už zažil na vlastnej koži to podľa teba "neexistujúce" silent data corruption. Bolo to na rôznych externých USB diskoch. Výrobca nastavil aby disk pri nečitateľnom sektore vrátil nuly bez chyby a bez S.M.A.R.T korekcie. Obvykle po zaplnení nezmyselne malej rezervy pre SMART. Tých 200 rezervných bokov stačilo keď disky mali rádovo jednotky GB.

[Andrej]

NULA silent corruption.

Anekdoty mě příliš nezajímají. Podstatná jsou data. Slova o zaklínadlech prodejců jsou z oblasti konspiračních nesmyslů, nikoliv faktů. 190 TB a nějaké (předpokládám) jedno datové centrum je hodně malý vzorek na to, aby se z něj dalo cokoliv vyvozovat.

Především bych se jízlivě pousmál nad tím, že někdo počítá checksumy teprve až z toho, co mu filesystém vrací, nikoliv před zápisem těch dat, a myslí si, že tím něco "dokazuje". Když se data poškodí právě při zápisu, což je velmi pravděpodobné, pak se samozřejmě můžou tisíckrát "konzistentně" přečíst a všechno bude vypadat na jedničku.

Je překvapivé, na kolik hluboce zakořeněných pověr a iluzí o ukládání dat a o redundanci člověk narazí pokaždé, když zmíní prostý fakt, že RAID bez checksumů na úrovni filesystému je mnohem méně redundantní, než by se mohlo zdát.

[Rats]

A ze voni tomu soudruzi z RedHatu rozumi mene nez vy, to je na tom akorat divny... https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html

Zapomente na BTRFS, neni to prvni "genialni" technologie, ktera na svou "genialitu" umrela.

[MP]

Sorry, ale RedHat to dela proto, ze nema vyvojare na btrfs a pokud oni neco prodavaji, tak to musi podporovat. A tezko muzou podporovat neco, na co nemaji vyvojare. Navic, kdyz maji vlastni xfs ve vyvoji.

[Rats]

Ehm ... zduvodneni RedHatu je uplne jine, dohledejte si.

[Andrej]

Btrfs se nijak nechystá umřít a nikde není psáno, že to, na co je v RHEL nějaká komerční podpora, je v nějakém smyslu normou.

Kromě toho filesystém s checksumy není žádná závratná genialita; je to nezbytnost. Zda nakonec převládne Btrfs nebo jiný, novější a pokročilejší filesystém, to už je jiná otázka. Nicméně s neustálým růstem datových úložišť to bez checksumů nepůjde.

[MP]

Rozdeleni je takto (4 disky):

Logicky:

1] System: 2x disk (sda,sdb), mdadm raid1, disklabel type: dos

2] Data: 4x disk, btrfs raid1, dva disky jsou z 1], dva jsou extra (sdc,sdd) s disklabel type: gpt

System nabehne (mdadm ok), ale btrfs nenabehne, ma problem s tema dvema diskama v gpt.

K tem hlaskam, upravuju:

btrfs device ready /dev/sda3 = ok

btrfs device ready /dev/sdb3 = ok

btrfs device ready /dev/sdc1 -> not block device

btrfs device ready /dev/sdd1 -> not block device

Pritom ty gpt disky jsou v linux systemu normalne videt.

[MP]

Zasr...neupravovaci forum. Takze dodatek...

1] mdadm - samostatne oddily pro mdadm

2] raid1 -> raid10, samostatne oddily pro btrfs

[Trubicoid2]

Nějak nechápu, kdy dostaneš tu hlášku?

Jestli systém jede, ukaž co je v /etc/fstab, jde ten btrfs namountovat ručně? Co to říká? Případně co je v dmesg?

A co lsblk?

[Trubicoid2]

A ještě pro úplnost cat /proc/mdadm

[Jendа]

Je to /proc/mdstat. A jinak ještě /proc/partitions a možná dmesg. A file a file -Ls /dev/sdxy, když to tvrdí, že to není block device.

[MP]

UUID=xxxx /btrfs btrfs device=/dev/sda3,device=/dev/sdb3,device=/dev/sdc1,device=/dev/sdd1 0 0

MDADM s tim nema nic spolecneho az na to, ze sdili disky, takze netreba ho resit.

Zbytek veci, az to zkusim znovu prehodit, ale fakt jsem pred dalsim pokusem potreboval videt mozne navrhy, kde je problem.

[MP]

Takhle to vypada na funkcnim HP serveru:

# lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda       8:0    0 149.1G  0 disk
├─sda1    8:1    0   9.3G  0 part
│ └─md0   9:0    0   9.3G  0 raid1 /
├─sda2    8:2    0   3.7G  0 part  [SWAP]
└─sda3    8:3    0   136G  0 part
sdb       8:16   0 149.1G  0 disk
├─sdb1    8:17   0   9.3G  0 part
│ └─md0   9:0    0   9.3G  0 raid1 /
├─sdb2    8:18   0   3.7G  0 part  [SWAP]
└─sdb3    8:19   0   136G  0 part  /btrfs
sdc       8:32   0 153.4G  0 disk
└─sdc1    8:33   0   137G  0 part
sdd       8:48   0 153.4G  0 disk
└─sdd1    8:49   0   137G  0 part

#file /dev/sdc1
/dev/sdc1: block special (8/33)
# file /dev/sdc
/dev/sdc: block special (8/32)

[MP]

#file -Ls /dev/sdc1
/dev/sdc1: BTRFS Filesystem sectorsize 4096, nodesize 16384, leafsize 16384, UUID=72c03b5f-3322-4d59-822f-55173a25f97c, 13280161792/586286104576 bytes used, 4 devices

# file -Ls /dev/sdd1
/dev/sdd1: BTRFS Filesystem sectorsize 4096, nodesize 16384, leafsize 16384, UUID=72c03b5f-3322-4d59-822f-55173a25f97c, 13279657984/586286104576 bytes used, 4 devices

# file -Ls /dev/sdd
/dev/sdd: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 321672959 sectors, extended partition table (last)

# file -Ls /dev/sdc
/dev/sdc: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 321672959 sectors, extended partition table (last)

[trubicoid2]

nojo, my to ale chceme videt na tom druhem serveru, kde to nefunguje: lsblk, mount /tobtrfs a dmesg

a neni mozny, ze na druhym serveru se proste prohazi sda-b-c-d? pak hleda treba sdc3, coz neni

je asi pak potreba upravit /etc/fstab a hotovo

ten /etc/mdstat - nekdy mdadm nadetekuje automagicky jakesi pole a blokuje ty partice, to je jen pro jistotu

[MP]

lsblk /dev/sdc1 -> not a block device
lsblk /dev/sdd1 -> not a block device

lsblk /dev/sdd
name maj:min rm size ro type mountpoint
sdd 8:32 0 153G 0 disk

file -Ls /dev/sdd1 -> no such file or directory

# file -Ls /dev/sdd
/dev/sdd: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 321672959 sectors, extended partition table (last)

# lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda       8:0    0 149.1G  0 disk
├─sda1    8:1    0   9.3G  0 part
│ └─md0   9:0    0   9.3G  0 raid1 /
├─sda2    8:2    0   3.7G  0 part  [SWAP]
└─sda3    8:3    0   136G  0 part
sdb       8:16   0 149.1G  0 disk
├─sdb1    8:17   0   9.3G  0 part
│ └─md0   9:0    0   9.3G  0 raid1 /
├─sdb2    8:18   0   3.7G  0 part  [SWAP]
└─sdb3    8:19   0   136G  0 part  
sdc       8:32   0 153.4G  0 disk
sdd       8:48   0 153.4G  0 disk


cat /proc/mdstat -> pouze raid md0

mount /dev/sda3 /btrfs
BTRFS error (device sdb3): failed to read the system array: -5
BTRFS ERROR (device sdb3): open_ctree failed
mount: wrong fs type, bad option...blablabla

fdisk -l /dev/sdd

/dev/sdd1 1(start) 326...(end) 321....(sectors) 153G(size) ee(id) gpt(type)

Dost otazka, proc fdisk particii vidi a lsblk ne...

[R]

Pozri do dmesg - ci particie vidi kernel a porovaj tam velkosti diskov v sektoroch, ci nahodou nie su na novom serveri mensie.

[trubicoid2]

je to cele jakesi divne, bych si taky myslel, ze kousek tech gpt disku bude chybet, sezere to radic? bud na novem nebo na starem a ty velikosti nebudou sedet

nemaj ty disky trebas aktivni HPA? nejlip jen v jednom z tech serveru? to by taky bylo v dmesg, neco jako:

dmesg | grep ata2

[ +0,000003] ata2: SATA max UDMA/133 abar m2048@0xfb121000 port 0xfb121180 irq 26

[ +0,000496] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

[ +0,012802] ata2.00: HPA detected: current 187547647, native 234441648

[ +0,001850] ata2.00: ATA-9: INTEL SSDSC2BW120A4, DC32, max UDMA/133

[ +0,000003] ata2.00: 187547647 sectors, multi 16: LBA48 NCQ (depth 31/32), AA

[ +0,011928] ata2.00: configured for UDMA/133

dulezity je, aby to sectors bylo UPLNE stejny na obou pocitacich

fdisk je chytry, ten se diva i na konec disku, kde je zalozni gpt, ale treba ta na zacatku chybi?

druha moznost je, ze na diskach je jakasi divna kombinace stareho mbr a noveho gpt?

bych asi disky prepsal nulama - jak zacatek, tak konec a udelal na ne mbr a pak znova nasypal data z partic pomoci dd

taky u tech GPT ten fdisk -l vypada presne jak? Ty pises start 1? To jsou bloky 512b? To by teda nemelo bejt, to ti udelal kdo? Schvalne se zacina az na 2048, nebo dokonce 8192, jestli toto neni ten problem?

taky je videt, ze jakoby ta partice neni pres cely disk, je tam jeste neco?

[trubicoid2]

a taky misto toho fdisk zkus pouzid gdisk nebo sgdisk, ty jsou na GPT lepsejsi

[R]

Kedze v BIOSe radica vytvoril nejaky RAID, tak tato informacia musi byt niekde na diskoch ulozena. Na zaciatku zjavne nie, to by rozhasilo aj MBR (na zaciatku to maju nejake stare SCSI Adaptecy, raz som z takeho RAID1 disku zachranoval data - po poruche jedneho disku sa RAID1 pole rozpadlo...). Takze to bude asi na konci a o tuto cast bude disk "vyzerat" mensi. Ak to teda nerobia ako prasce v Hightpoint, co pouzivali nejaky sektor pred prvou particiou a potom to rozbijalo GRUB.

[trubicoid2]

to by se poznalo, ze budou ty size mensi nebo jine na jednom nez na druhem pocitaci

[MP]

Takze...

HP:

fdisk -l /dev/sdd
Disk /dev/sdd: 153.4 GiB, 164696555520 bytes, 321672960 sectors

[    2.759481] sd 1:0:1:0: [sdd] 321672960 512-byte logical blocks: (165 GB/153 GiB)

Dell:

fdisk -l /dev/sdd
Disk /dev/sdd: 152.9 Gib, 164148281344 bytes, 320602112 sectors

sd 0:2:3:0: [sdd] 320602112 512-byte logical blocks: (164 GB/ 153 GiB)

gdisk: disk size smaller than the main header indicates ! Loading secondary header from the last sector of the disk !
Invalid backup GPT header, but valid main...............

Na Dellu je ten disk z nejakeho duvodu mensi...btw, je tam Perc 6i radic.

[MP]

Mimochodem, ten prvni oddil na sdd/sdc zacina na 2048, fdisk to na Dellu vidi na pozici 1, na HP na pozici 2048, gdisk to na Dellu taktez vidi na 2048...

fdisk /dev/sdd1 (start) 1

gdisk /dev/sdd1 (start) 2048

HP:
/dev/sdd1   2048 287311871 287309824  137G Linux filesystem
Dell:
/dev/sdd1   1 321672959 321672959 153.4G ee GPT

V obou pripadech ale je ten disk na Dellu videt mensi, resp. ten Dell zamenuje oddil za cely disk zrejme (minus chybejici kus).

[MP]

a tresnicka...

HP:
hdparm -N /dev/sdd: max sectors 321672960, HPA is disabled

Dell:
hdparm -N /dev/sdd: max sectors 0/1, HPA is enabled
SG_IO bad/missing sense data, sb[]:

ACHJO!! Pitomy Delly.

[alkoholik]

Cely problem bude v "raid0 virtual device". Radic si musi nekam zapsat metadata, ze ten disk je soucasti pole.
Taky milujes HW RAIDy?

[alkoholik]

A troska spatnych zprav na zaver.

[MP]

Kazdy raid musi nekde mit metadata. A HW raidy maji dve vyhody - clovek neresi boot, neresi manualni reattach mrtvych disku.

Jinak, reseni nakonec bylo zrusit GPT a dat tam MBR a voila, funguje to.

[alkoholik]

Kdybys videl, co mi nedavno udelal zrovna PERC 6i s filesystemem, tak si tahle moudra odpustis.
A 'mrtvy' disk jsme resili hned vedle. U PERCu nebo backplanu odesel jeden port a museli jsme disk pripojit pres jiny. To je pak neskutecny ojeb pres globalni HS.

[trubicoid2]

asi ten raid rozpozna mbr a na ten disk nesaha. disk s gpt mu pripadne prazdny, tak si kus ukousne na ty metadata

ale je to tezka magie :)

[dustin]

Jen pro zajímavost a srovnání - HP SmartArray (testoval jsem P800/220i a P410) si na konci disku zabere 32MB pro svá data. Když se vyrobí jednodiskový raid0 (jbod to neumí), nabídne OS raw disk od začátku po size-32MB. Takže kdyby se vzal disk z jiného kompu, který nemá partišnu až do konce, partišny i jejich filesystémy normálně pojedou (s partišnou až do konce může být nabořený její filesystém).

Je docela možné, že něco podobného dělá i ten Dell a nelíbí se mu chybějící secondary GPT tabulka, která je na konci.

[R]

Ake velke su tie disky? Kedze tam mas GPT, tak mam podozrenie, ze su vacsie ako 2 TB. A PERC 6 take disky nepodporuje...takze sa pozri, ake velke ich vidi kernel.

[MP]

160GB

[Jendа]

LOL právě jsem zjistil, že ten úžasný superbezpečný FS klidně namountuje truncatnutý FS read-write, normálně tam člověka nechá zapisovat soubory, nikomu nic neřekne, a časem hodí držku a taintne kernel

(metodika: vyrobit 200MB FS, připojit, zapsat 19MB soubor, odpojit, truncatnout na 100 MB, připojit, zapsat malý soubor, sync, odpojit, připojit, soubor tam je a nikdo neřekl žádnou chybu, pustit scrub, pozorovat, jak počítač exploduje)

[Petr]

Vzdyt je to vlastnost toho Beta FS...

[karlik]

Ale ale, vždyť ještě nedávno mne tady málem ukamenovali za to, že jsem poukázal na možné chyby v tomto super FS, a vy takhle...

[karlik]

Prostě vyhoď ten Perc 6i a budeš happy (udělal jsem to po testech s PERC H200):

https://forums.freenas.org/index.php?threads/hardware-recommendations-read-this-first.23069/

If the controller you want to use is an Adaptec, Dell Perc, Highpoint, or some no-name brand you shouldn't even try to use them. All of these may or may not "work" but you'll find out later they don't properly handle SMART monitoring, SMART testing, passing of errors from the disk to the system, etc. Don't put your data at risk and go with *any* of these brands. You can thank us for saving your data later.

If you are using a Dell Perc and think that when we say "JBOD" we mean RAID0 of single disks, you are in error. JBOD is not the same as a RAID0 of a single disk, and you are making a grave error by thinking otherwise. -----

[R]

Na toto pouzitie (priamy pristup k HDD) je akykolvek HW RAID radic nevhodny. Tiez som mal nejaky Megaraid a chcel som ho vyuzit na testovanie diskov - ale jeho firmware mi to rozumne nedovolil. Musel som kupit lacny LSI, ktory sa da preflashovat do iT modu.

V serveroch pouzivame PERC (najstarsie su PERC5) na RAID1 a RAID6 a to funguje bezproblemov. Dokonca aj SMART funguje, staci pouzit "-d megaraid".