Btrfs a diskové oddíly

14.6.2019 13:58 | Přečteno: 2412× | Za vším hledej Linux | poslední úprava: 14.6.2019 14:08

Asi před čtrnácti dny mne poprosil kamarád, jestli bych mu nedal k dispozici svůj archiv – šlo cca 3TB dat. A protože se mi doma válel jeden plonkovní 4TB Seagate Desktop SSHD, nakopíroval jsem data na něj a ten mu dal k dispozici. Ovšem po zkopírování cca 250GB mu ten disk velice podivným způsobem umřel. Dost mě to vyplašilo, protože další dva disky tohoto typu jsem "dočasně" použil u svého domácího úložiště – a právě ten, co mu chcípnul jsem měl připravený pro případ, že by se jeden z nich odebral do věčných lovišť. Rozhodl jsem se jich tedy urychleně, za každou cenu, zbavit. Abych mohl přejít k jádro pudla, je nutné zabrousit do historie těchto disků.

Z temné historie použitých disků

Disk, který chcípnul, byl jedním ze tří disků tohoto typu, které jsme experimentálně zakoupili na jaře 2015. Chtěl jsem je použít jako "HW podkladovou vrstvu" pod Gluster FS – do každého ze tří nodů, byl umístěn jeden disk tohoto typu. Ovšem ukázalo se (jak se můžete dočíst zde), že při práci se soubory většími než 4GB IO výkon těchto disků prudce klesal.

Neuplynulo ani půl roku a jeden z nich velice ošklivým způsobem chcípnul. Protože jsme do té doby neměli s SSHD disky žádnou reálnou zkušenost, napsal jsem tehdy o tom ostatním kolegům mail, z něhož cituji:

* Když takový disk odejde, tak stejně jako u vadného SSD - jsou všechna
  data v tahu
* Navíc, když odejde, tak to v systému vyvolá kernel panic, který nějakým
  způsobem nabourá i souborové systémy, které s tím diskem nemají nic
  společného - včetně virtuálních - zřejmě je to proto, že se to tomu
  virtualizačnímu stroji pomíchá v paměti.
* Ve smartu se u vadného SSHD žádné errory neobjeví - pouze nedoběhne do
  konce long test.
 
Protože mám možnost srovnání s nepoškozeným diskem stejného typu, tak jen
pro srovnání...
 
Takhle vidí systém 4TB SSHD disk co je v pořádku..
   8       48 3907018584 sdd
   8       49 3907017543 sdd1
 
Takhle vidí systém stejný typ 4TB disk co je vadný (povšimněte si počtu
sektorů)
   8       32 1759534936 sdc

I když byl vadný disk tehdy vyreklamován, okamžitě jsem přestal tyhle disky používat. Od té doby se nám válely asi dva roky bez užitku ve skříni.

Když ti teče do bot…

Pak jsem zakoupil do svého domácího úložiště EZ Swap M2500 Series - 2.5" Mobile Rack (12 Bay) s cílem nahradit postupně 3,5" disky za 2,5". Jenže jsem neměl k dispozici dost volných SATA portů a kupovat řadič jen kvůli tomu, abych mohl dočasně žonglovat s daty, se mi nechtělo. Použil jsem tedy dva z těchto disků, abych mohl data sklepat a uvolnit alespoň dva SATA porty pro dva nové 2TB disky Seagate Samsung SpinPoint M9T. Od té doby tam zůstaly. Chlácholil jsem se tím, že ten stroj nejede pořád a pokud by jeden z těch disků umřel způsobem, jaký jsem již jednou zažil, tak si s tím Btrfs v režimu raid1 poradí, protože bude mít nepoškozený datový blok i jinde.

Neměl jsem však ujasněnou strategii do budoucna. Cena velkokapacitních rotačních 2,5" SATA disků je stále poměrně vysoká a k tomu abych mohl zapojit všechny sloty, jsem potřeboval řadič. Také deska stávajícího stroje (MSI 870A-G54) už je také za hranicí plánované životnosti. Nicméně alespoň v tomto směru mám jasno. Nová deska + Ryzen 5 s integrovanou grafikou + paměti, vyjde zhruba na 13,5 tisíce.

Btrfs warning v logu při stěhování dat

Moje dlouhodobé dilema vyřešila událost, zmíněná v perexu. Pokud chcípne deska, tak se k uloženým datům sice nedostanu, ale nepřijdu o ně. Kdežto pokud chcípnul jeden z těch 4TB disků a zbylá kapacita ostatních disků nestačila k tomu, abych ho mohl vyřadit a nahradit novým – tak by reálně hrozilo, že dřív než stihnu něco udělat, chcípne ještě jeden. A to už by hrozilo tím, že bych o nějaká data přišel. Půjčil jsem si tedy řadič, zapojil další sloty a nakoupil nové 2TB 2,5" disky, abych na ně data z rizikových SSHD disků přestěhoval.

Jako první šel ale na řadu starší 2TB 3,5" diskvSeagate Barracuda 7200.14 (AF) ST2000DM001-9YN164 , který již vykazoval ve smartu nějaké chyby a zcela reálně celé Btrfs pole zpomaloval. Během přesunu se začalo v logu, po každém přestěhovaném bloku dat, objevovat následující varování:

[148930.199536] WARNING: CPU: 0 PID: 9953 at fs/btrfs/ctree.h:1633 btrfs_update_device+0x1a8/0x1c0 [btrfs]
[148930.199540] Modules linked in: snd_hrtimer snd_seq snd_seq_device edac_mce_amd kvm_amd ccp rng_core snd_hda_codec_realtek kvm snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio serio_raw irqbypass pcspkr k10temp snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm evdev sg snd_timer snd soundcore sp5100_tco pcc_cpufreq acpi_cpufreq nfsd parport_pc ppdev lp auth_rpcgss nfs_acl lockd grace parport sunrpc ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod ohci_pci radeon ata_generic psmouse i2c_algo_bit xhci_pci ttm xhci_hcd pata_jmicron drm_kms_helper i2c_piix4 ehci_pci ohci_hcd ehci_hcd r8169 realtek libphy usbcore ahci libahci sata_mv usb_common libata scsi_mod drm button
[148930.199611] CPU: 0 PID: 9953 Comm: btrfs Tainted: G        W         5.0.0-trunk-amd64 #1 Debian 5.0.2-1~exp1
[148930.199614] Hardware name: MSI MS-7599/870A-G54 (MS-7599), BIOS V17.17 01/13/2012
[148930.199686] RIP: 0010:btrfs_update_device+0x1a8/0x1c0 [btrfs]
[148930.199691] Code: 3d ff ff 4c 89 f7 45 31 c0 ba 10 00 00 00 48 8b 8b a0 00 00 00 4c 89 e6 e8 85 3d ff ff 4c 89 f7 e8 7d 1f fd ff e9 dd fe ff ff <0f> 0b eb c2 41 bd f4 ff ff ff e9 d6 fe ff ff e8 34 fd bb f0 0f 1f
[148930.199694] RSP: 0018:ffffa6c7810a7b08 EFLAGS: 00010206
[148930.199698] RAX: 0000000000000fff RBX: ffff91a5da51d000 RCX: 000003a3816d1e00
[148930.199700] RDX: 0000000000001000 RSI: 0000000000003efa RDI: ffff91a45b5673b0
[148930.199703] RBP: ffff91a4c338ab60 R08: ffffa6c7810a7ab8 R09: ffffa6c7810a7ac0
[148930.199705] R10: 0000000000003000 R11: 0000000000000003 R12: 0000000000003eda
[148930.199707] R13: 0000000000000000 R14: ffff91a45b5673b0 R15: ffff91a4c338ab60
[148930.199711] FS:  00007f5c8d5bf8c0(0000) GS:ffff91a5e7600000(0000) knlGS:0000000000000000
[148930.199714] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[148930.199717] CR2: 00007fb8ce1d7930 CR3: 00000001aeb2c000 CR4: 00000000000006f0
[148930.199719] Call Trace:
[148930.199796]  btrfs_remove_chunk+0x29e/0x710 [btrfs]
[148930.199869]  btrfs_relocate_chunk+0x7c/0xa0 [btrfs]
[148930.199938]  btrfs_shrink_device+0x1db/0x570 [btrfs]
[148930.200009]  ? btrfs_find_device_by_devspec+0x70/0x1a0 [btrfs]
[148930.200078]  btrfs_rm_device+0x171/0x570 [btrfs]
[148930.200147]  ? btrfs_ioctl+0x1daf/0x2da0 [btrfs]
[148930.200155]  ? __check_object_size+0x15d/0x189
[148930.200224]  btrfs_ioctl+0x2a92/0x2da0 [btrfs]
[148930.200232]  ? strncpy_from_user+0x4f/0x1b0
[148930.200238]  ? _copy_to_user+0x26/0x30
[148930.200243]  ? cp_new_stat+0x150/0x180
[148930.200250]  ? do_vfs_ioctl+0xa4/0x630
[148930.200255]  do_vfs_ioctl+0xa4/0x630
[148930.200260]  ? __do_sys_newstat+0x48/0x70
[148930.200266]  ksys_ioctl+0x60/0x90
[148930.200272]  __x64_sys_ioctl+0x16/0x20
[148930.200277]  do_syscall_64+0x53/0x100
[148930.200283]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[148930.200288] RIP: 0033:0x7f5c8d6b2427
[148930.200292] Code: 00 00 90 48 8b 05 69 aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 aa 0c 00 f7 d8 64 89 01 48
[148930.200295] RSP: 002b:00007ffeaf316078 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[148930.200298] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5c8d6b2427
[148930.200301] RDX: 00007ffeaf317098 RSI: 000000005000943a RDI: 0000000000000003
[148930.200303] RBP: 0000000000000001 R08: 0000000000000400 R09: 0000000000000078
[148930.200305] R10: fffffffffffffa4a R11: 0000000000000206 R12: 00007ffeaf318218
[148930.200307] R13: 0000000000000000 R14: 0000000000000003 R15: 0000000000000003
[148930.200313] ---[ end trace d07b0193aa2b8913 ]---

Používám Btrfs již dlouho, takže vím jak vypadají hlášky, které signalizují problém. Tohle varování pouze signalizuje, že se nepodařilo po přesunu bloků aktualizovat hodnotu pro nějaké info. Takže jsem to ignoroval. Ale nebudu zastírat, že mi stále vrtá hlavou co za tím vlastně vězí. Pak jsem vyhodil první z těch 4TB SSHD. A pořád tahle hláška. Nedalo mi to a začal jsem pátrat ve zdrojáku jádra a v jeho historii změn, jestli někdo neřešil něco podobného. Ale nic kloudného jsem nenašel. A když jsem začal stěhovat data i z toho druhého SSHD disku, zase to upozornění.

Zakopaný pes?

Až dnes ráno, jsem natrefil na zprávu, u které mou pozorost upoutal příkaz:

btrfs inspect-internal dump-super /path/to/btrfs/device

Ze zvědavosti, jsem ho zkusil aplikovat nejdřív na diskový oddíl 4TB disku, ze kterého jsem data čerstvě odstěhoval:

stroj :~# btrfs inspect-internal dump-super /dev/sdi1
superblock: bytenr=65536, device=/dev/sdi1
---------------------------------------------------------
ERROR: bad magic on superblock on /dev/sdi1 at 65536

Jelikož jde o příkaz, který není destruktivní (vypisuje pouze informace o superbloku), poštval jsem ho i na diskový oddíl 4TB disku, který jsem zrovna stěhoval pryč:

stroj :~# btrfs inspect-internal dump-super /dev/sdj1
superblock: bytenr=65536, device=/dev/sdj1
---------------------------------------------------------
csum_type               0 (crc32c)
csum_size               4
csum                    0x8c13b15f [match]
bytenr                  65536
flags                   0x1
                        ( WRITTEN )
magic                   _BHRfS_M [match]
fsid                    10000000-0000-0000-0000-000000000000
metadata_uuid           10000000-0000-0000-0000-000000000000
label                   main
generation              463137
root                    16300501598208
sys_array_size          258
chunk_root_generation   463136
root_level              1
chunk_root              6505365504
chunk_root_level        1
log_root                0
log_root_transid        0
log_root_level          0
total_bytes             22004366888960
bytes_used              6702494769152
sectorsize              4096
nodesize                16384
leafsize (deprecated)   16384
stripesize              4096
root_dir                6
num_devices             10
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x161
                        ( MIXED_BACKREF |
                          BIG_METADATA |
                          EXTENDED_IREF |
                          SKINNY_METADATA )
cache_generation        463137
uuid_tree_generation    463137
dev_item.uuid           9689301d-abf7-41ab-86fb-72c458eb09e2
dev_item.fsid           10000000-0000-0000-0000-000000000000 [match]
dev_item.type           0
dev_item.total_bytes    4000785964544
dev_item.bytes_used     3132104900608
dev_item.io_align       4096
dev_item.io_width       4096
dev_item.sector_size    4096
dev_item.devid          3
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

A pak jsem zkusil tenhle příkaz zavolat ne na diskový oddíl, ale rovnou na zařízení jako takové. A ejhle!

stroj :~# btrfs inspect-internal dump-super /dev/sdj
superblock: bytenr=65536, device=/dev/sdj
---------------------------------------------------------
csum_type               0 (crc32c)
csum_size               4
csum                    0x1de26591 [match]
bytenr                  65536
flags                   0x1
                        ( WRITTEN )
magic                   _BHRfS_M [match]
fsid                    845aeed6-5caa-463b-aeb3-234647e1c791
metadata_uuid           845aeed6-5caa-463b-aeb3-234647e1c791
label                   backup
generation              1010
root                    837419008
sys_array_size          129
chunk_root_generation   1006
root_level              0
chunk_root              20987904
chunk_root_level        0
log_root                0
log_root_transid        0
log_root_level          0
total_bytes             4000787030016
bytes_used              393216
sectorsize              4096
nodesize                16384
leafsize (deprecated)   16384
stripesize              4096
root_dir                6
num_devices             1
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x161
                        ( MIXED_BACKREF |
                          BIG_METADATA |
                          EXTENDED_IREF |
                          SKINNY_METADATA )
cache_generation        1010
uuid_tree_generation    1010
dev_item.uuid           87bc4668-6acd-4873-ad19-1dfa636d1301
dev_item.fsid           845aeed6-5caa-463b-aeb3-234647e1c791 [match]
dev_item.type           0
dev_item.total_bytes    4000787030016
dev_item.bytes_used     839758381056
dev_item.io_align       4096
dev_item.io_width       4096
dev_item.sector_size    4096
dev_item.devid          1
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

Ukázalo se, že na tom disku už v minulosti bylo Btrfs. Ovšem nikoliv nad logickým oddílem, nýbrž nad celým diskem. A stejně tak tomu bylo i u toho druhého 4TB disku. Obvykle obsah celého disku před novým použitím přepisuji nulami, ovšem v tomto případě jsem to neudělal, protože jsem nechtěl u těch hybridních disků zbytečně opotřebovávat buňky interního ssd.

Překontroloval jsem i ostatní disky a u těch jsem nic podobného nenašel, takže jsem si myslel že příčinou toho varování, které se objevovalo v logu bylo právě tohle, jelikož velikost Btrfs z reliktního záznamu (total_bytes=4000787030016) neodpovídá aktuální velikosti pole (total_bytes=22004366888960)

Ale kdepak

Po přesunu dat z velkých 4TB disků a onoho vadného následovala operace. Vykuchal jsem koš s těmi dvěmi 4TB disky a dva boxy se dvěma 2TB 3,5" disky. Věděl jsem, že jeden z nich je ten vadný. A ten další bylo nutné vykuchat abych mohl zapojit všechny sloty tom boxu na 2,5" disky.

Po úspěšné operaci, jsem nahodil systém, zapíchnul přes externí USB ten disk který bylo nutné rovněž vyoperovat. Vrazil jsem do boxu zbylé 2x2TB ve 2,5", přidal je do Btrfs pole a odstartoval vyhození diskového oddílu z disku připojeného přes USB adaptér z pole. A opět ta hláška. Takže nevím.

Asi za 14 hodin tahle operace úspěšně skončila. Spustil jsem scrub a příjemně mne překvapilo, jak relativně svižně proběhla. 12,2TB se překontrolovalo cca za 4,5 hodiny.

Pokud si kladete otázky…

Proč byly původně pro Btrfs použity celé disky, bez MS-DOS či GPT tabulky?

Jednoduše proto, že na nich nic jiného než data být nemělo. Diskové oddíly dávají smysl v okamžiku, pokud potřebujete umístit na blokové zařízení zavaděč, abyste z něj mohli nabootovat. Pro logický oddíl na 4TB discích by navíc bylo nutné GPT. To by ovšem znamenalo další modul do jádra zavaděče GRUB2, aby si mohl sestavit pole aby z něj pak mohl nabootovat.

To lze, nabootovat systém ze subvolume Btrfs pole které je složené z několika disků?

Ano, ale musíte použít na disku logické oddíly a mít vyhrazené místo pro zavaděč. U MS-DOS tabulky se zavaděč cpe do MBR, jenže MS-DOS tabulka má svůj limit na hranici 2TB, takže pokud kombinujete větší disky, je lepší použít GPT. Pokud plánujete, že budete používat pouze disky o velikost 2TB (jako já), vystačíte si s MS-DOS

Proč disky 2TB a ne rovnou 4TB?

Důvodů by se našlo hned několik, ale tím hlavním je pro mne cena. Ta se v současné době pohybuje u rotačního disku cca 1–1,5 tis./TB a stoupá víceméně lineárně až do kapacity 10TB. Kdežto u SSD disků začíná cca na 4 tis./TB a stoupá exponenciálně na aktuálně dostupné maximum 4TB. Takže když mi chcípne disk 1x2TB, tak to znamená akutně vysolit cca 2 litry. U rotačního 4TB disku by to byl víc než dvojnásobek. A za cenu takhle obludně velkého SSD disku bych koupil celou sadu nových rotačních disků o stejné kapacitě. Koupí většího rotačního disku bych sice získal o něco větší kapacitu. Ale na co? A u menších disků nepotřebuji udržovat velkou rezervu. Stačí jen tolik volného místa, aby se měly kam přesunout data z jednoho chcíplého disku. Čím více menších disků, tím víc jich může časem pochcípat aniž by to muselo skončit ztrátou dat.

Nekoupil jsem naráz disky do všech slotů proto, aby mi neskončila záruka u všech disků najednou. A časem, jestli se ceny velkokapacitních SSD disků dostanou na nějakou rozumnou hladinu, je možná začnu nahrazovat jimi.

Dalším je kapacita. V současné době mám celkovou kapacitu 18.19TiB, ze které mám reálně obsazeno 12.19TiB. A to nemám plně obsazeny 2TB disky všechny sloty.

       

Komentáře

[xxx]

Diskove oddily davaji smysl vzdycky, protoze to jak funguji veci bez diskovych oddilu nikdo netestuje. Ale na druhou stranu, kdyz nekoho nerozhodi stacktrace v logu pri kopirovani dat...

[kralyk z abclinuxu]

Ale na druhou stranu, kdyz nekoho nerozhodi stacktrace v logu pri kopirovani dat...

Asi tak. Absolutně nepochopim, jak může někdo neironicky / na svoje reálný data používat filesystem, který vykazuje takovouhle nestabilitu a asi zřejmě špatnou testovanost. No ale můj problém to není a kdo chce kam, pomožme mu tam...

Nicméně zápisek je pro mě přínosem v tom, že je fajn vědět, že btrfs je stále ještě v takovémhle stavu, takže díky za to...

[Want]

Kdybych se měl vzrušovat kvůli kdejakého upozornění, tak je dávno po mě. Btrfs je jediný FS, na kterém jsem, co mi paměť sahá nepřišel o data. Každý ať si používá co chce. Já o data přijít nechci, proto je moje volba taková, jaká je.

[xxx]

Vis co. Tvuj boj. Pred deseti lety byla jasna volba mdraid1, 5 nebo 6. Nad tim tehdy snad uz ext3. A fungovalo to. Vytazeni disku za chodu, resync, atd. Neko tehdy zkousel xfs a stalo to za hovno. Ne vykonem ale spolehlivosti. Btrfs tehdy snad ani neexistoval.

Nicmene napsat "Já o data přijít nechci" a zaroven napsat blogovej zapisek o tam, jak mam v logu chyby o kterejch vim hovno co znamenaj. Jako lol... Hlavne se nevzrusuj.

[Want]

Btrfs tehdy snad ani neexistoval.

Mluvíš z hladu. Viz níže.

Jinak "warning" není chyba. Pokud tuhle nuanci nechápeš, nechápu pro změnu já, co děláš v tomhle oboru.

[_]

warning je vole varovani

ne neco, co mas mit na haku

[Want]

Další, co se fakt "vyzná".

Varování je upozornění, že je asi něco jinak než by mělo být. A je milion důvodů proč.

Pokud bys měl řešit každý prd co tohle posílá, tak brzy umřeš.

Tím, co by ti mělo zvedat obočí je error. Protože to už je zcela reálný projev konkrétní chyby, kterou je třeba najít a ošetřit.

[JS1]

U aplikace bych i souhlasil, ale u filesystemu? Tam error znamena ztratu dat, a tudiz je varovani (asserce) treba brat vazne.

[Aleš Kapica]

Tam error znamena ztratu dat

Ano, jsou souborové systémy u kterých to platí beze zbytku a pokud je Btrfs v single mode, tak rovněž. Jenomže chyba, která vede ke ztrátě dat obvykle s warningem vůbec nesouvisí. Warning je warning. Nic víc, nic míň.

[kralyk z abclinuxu]

Warning je warning. Nic víc, nic míň.

To není pravda; není warning jako warning.

Ta hláška v dmesg a ten trace je AFAIK následek makra WARN_ON(). Čiliže to je něco jako jemnější varianta assertu, kdy něco je špatně, ale není to tak hrozný, aby kvůli tomu musel nastal panic a vzít s sebou celý systém. Nicméně slouží to na verifikaci invariantů (minimálně takový je účel), proto to taky bleje stack trace a další informace, aby se to dalo debugovat. Pokud btrfs narzí na chybu, měl by ji detekovat a nějakým vhodným způsobem sdělit uživateli. Pokud to v kódu naráží na WARN_ON() a ty musíš procházet zdrojáky jádra nebo někde jinde podrobně zkoumat, co se děje, tak je IMO něco špatně.

Souhlasim s tebou, že ten warning trace nemusí nutně být a asi není symptomem nějakého iminentního fatálního selhání, nicméně z mého pohledu ten trace i to popisováné chování a jak jsi zjišťoval, co je teda vlastně špatně, ukazuje na špatnou kvalitu toho kódu a/nebo nedostatečné testování.

[Aleš Kapica]

Nezjišťoval jsem to proto, že by mě to omezovalo. Ten warning souvisel nějak s přesouváním extentů, tak jsem chtěl zkusit zjistit jak. Věnoval jsem se tomu jen proto, že jsem na to zrovna měl čas. A ten teď nemám.

[marbu]

Diskove oddily davaji smysl vzdycky, protoze to jak funguji veci bez diskovych oddilu nikdo netestuje.

To je pravda. A nejen v případě oddílů, ale i všech voleb filesystému obecně. Pokud něco není buď default nebo popsáno jako doporučená konfigurace pro nějaký konrétní typ nasazení, není moc pravděpodobné, že by to někdo před vámi nějak vážně zkoušel, natož testoval.

Nicméně použití btrfs na dedikovaném blokovém zařízení bez oddílů není ten případ, protože btrfs v sobě zahrnuje jak volume management tak filesystém. Na druhou stranu existuje několik důvodů proč dávat brfs na oddíl: pokud chci mít na disku oddíl s jiným filesystémem (např. kvůli bootu nebo swapu), případně pokud chci btrfs šifrovat (pak se musí dát na LUKS volume).

Pokud chápu zápisek dobře, tak chyba byla naopak v tom, že se btrfs na dedikovaném zařízení dal na oddíl místo na celý disk.

[Heron]

Můžu se zeptat na důvod k přechodu na 2.5" disky? Když se v rychlosti podívám do Alzy, tak jsou dražší než 3.5" (bez překvapení) a navíc kromě jednoho jsou všechny 5400rpm. Jediný normální 2.5" disk (tedy 7200rpm) stojí 7 litrů. Nabídka 3.5" 2TB disků je mnohem pestřejší a za nižší cenu máš 7200rpm disk.

Jinak krabička na těch 12 disků je pěkná, ale už se nedělá (bez překvapení). Tenhle boj jsem vzdal, chtěl jsem mít taky alespoň 16 špuplíků na 3.5" disky, ale nic za normální cenu není a nemá to multiplier (tedy to chce ještě řadič). Takže nakonec za nižší cenu mám vedle sebe dva towery, v každým 8 disků (kombinace 4TB a 3TB), dva OS (Linux / BTRFS, FreeBSD / ZFS) a je to asi nejlepší řešení. Jak dojde místo na disky, bude třetí komp (a možná DragonFly s HAMMER, ale to se ještě uvidí).

[alkoholik]

Ba ba, WD VelociRaptoru je vecna skoda..

[Want]

Hlučnost (jsou tišší), spotřeba (míň žerou), objem (místo 3x3,5“ mám 12x2,5“). Rychlost? Na co? Je to úložiště. Pro mne je důležitější aby data přežily výpadek i několika disků, než abych se k nim dostal o chlup dříve. Mimochodem, koupil jsem ty 2TB disky po 1,5 litrů. To je dobrá cena, ne? Jo a ta krabka se dá koupit za 3,5 tisíce z USA, koukni na ebay.com K nám se nevozila nikdy.

[j]

Prosacuj frcy a hledej MD 1000. Da se koupit kolem 3 kil (dolaru nebo eur) + doprava. Je to pochopitelne pouze hloupa krabice na disky, takze je k tomu treba jeste sas radic.

[j]

Edit: Jop a v 2,5" samosebou naprosto vpohode koupis 10 i 15k disky, ale vic nez 10 uz nikdo nepouziva, protoze ssd. V sas variante pochopitelne.

[Heron]

Jasný, toho máme plný racky, ale tady se bavíme o domácím použití. Tuším MD3000 se nám válí v kanclu pod stolem.

Doma mám v jednom toweru 2x tohle (3x3.5" do dvou 5.25" pozic) a uvnitř case je ještě místo na cca 6 disků. Tj 12 disků v jednom toweru. To je pro mě tak akorát. Dneska není problém koupit PC case pro 12 disků rovnou (tuším nějaký Fractal).

[Max]

Já si koupil Centurion 590 (stále se prodává, a za krásných 1300,-Kč), který mohu osadit odzdola až nahoru 5" pozicemi. Dodává se jen s jedním boxem na disky, ale sehnal jsem i další na bazoši. Všechny boxy mají zepředu 120x120 větrák a některé novější umožňují kromě připojení 4x3,5" připojit z každého boku ještě 2,5" disk.
Boxy mají v sobě gumy na drobné odstínění vybrací jednotlivých disků.
I když mám case v prašném prostředí, tak díky přednímu prachovému filtru nemám uvnitř skoro žádný bordel a všechny disky se krásně chladí na nějakých 35 stupňů. Do té skříně mohu narvat tři klece, takže 12x 3,5" disk + případně další v podobě 2,5".
Nevýhodou je absence hotswapu, ale to mně netrápí, je to home storage a když potřebuji něco vyměnit nebo přidat (jednou za x let), tak prostě udělám odstávku a provedu údržbu.
Aktuálně nemám moc disků připojených, protože zatím jedu low power server, malá deska, intergovaný cpu, málo sata portů, nemožnost přidat větší řadič jak 4x sata atd. A SATA multiplikátor z Číny je nestabilní.
Zdar Max

[Max]

Jinak tedy jedu historicky mdadm+btrfs, pokud to někdy budu překopávat, tak hodím na Linux ZFS, protože čím více disků, tím větší failover je potřeba a 1+n je prostě málo, chce to aspoň 2+n.
Zdar Max

[Josef Kufner]

Mimochodem, viz statistiky od Backblaze. Dělají je už několik let.

[Want]

Ehm. Ten Btrfs souborový systém o kterém píšu byl naformátován a ty původní disky co v něm běží zakoupeny, necelý rok před tím než byl ten odkazovaný server spuštěn.

[Aleš Kapica]

Tohle byla poslední předtavba před implementací onoho boxu. A tady jsem popsal, jak jsem koupil ty disky a naformátoval ten Btrfs o kterém píšu v tomhle blogu. Takže pokud dobře počítám, tak ten souborový systém jeden 9 let. Za tu dobu přešel konverzí ze single Btrfs na Btrfs v raid1. Vystřídal několik disků a lehce nabobtnal. Pořád je to ale ten samý FS. Za tu dobu jsem zažil několik totálně zkolabovaných ext4, xfs, ntfs, o fat32 nemluvě.

[Heron]

Takže pokud dobře počítám, tak ten souborový systém jeden 9 let.

Ano, také mám na stařečkovi ještě tentýž FS, na / o kterém jsem kdysi v roce 2011 psal články. Výměny disků, konverze, pokusy s balance filtry, všechno přežil a žije dodnes.

[pc2005]

SSHD o_O to je hrozná technologie to už radši koupil SSD a HDD samostatně. BTW SMR disky jsou vlastně taky SSHD ne?

Jinak já si teďka v pátek koupil WD ultrastar 4TB, tak doufám, že jsem vybral správnej model (měli dva, 512 a 4k sektorovej) a že vydrží dlouho. Seagate green mě umřel asi půl roku po koupi.

[paul2no]

SMR co vím jsou spíš jako páska, resp. více pásek. Pokud v nějaké oblasti chci něco přepsat, musím zároveň přepsat vše až do konce té oblasti. Případně můžu připisovat na konec oblasti.

[pc2005]

Já mám za to, že tam mají vyrovnávací NAND flash pro tu přepisovanou stopu, aspoň u všech SMR disků co jsem viděl byla na PCB nandka.

[Max]

Výběr ti schvaluji. Jedná se o mojí oblíbenou novější modelovou řadu WD RE4. Vývoj šel takto : WD RE4 -> WD Gold -> WD Ultrastar DC
Jinak ten disk se nedělá s 512 sektory. Ve specifikamci má 4Kn nebo 512e. Rozdíl je v tom, že verze 512e má sektory 4k, ale prezentuje je jako 512. Našel jsem tento význam :

512e (emulated)
512n (native)
4Kn (4096 native)

Zdar Max

[pc2005]

No právě podle tohodle datasheetu "How to Read the Ultrastar Model Number" jsou dva modely E6 (512e SATA) a A6 (512n SATA). Myslím že právě okolo těch 4TB (ještě když se to jmenovalo RE) bylo možný mít obě varianty (asi něco ve stylu generace X a generace Y, ale pod stejným značením WD řady).