Ansy пісаў (а): Ну чаму ж не дзеля Wiki ... праблема-то з інструкцыяй была толькі ў тым, што працэдура дзеянняў у ўсталёўнікаў паказаная толькі намёкамі - а варыянтаў "праходжання квэста" там нашмат больш, і шмат ёсць дзе наблытаць . Калі гэта разжаваць больш падрабязна (а то яшчэ і з парай скрыншотаў) - была б цалкам рабочая HOWTO-шка для Wiki.
Не для Wiki таму, што ў мяне не было жадання рабіць викифицированную артыкул. Мой пост у дапамогу ўжо прасунутым юзерам, хто захацеў злавіць яшчэ больш вкусняшек ад сістэмы.
Натуральна. Jн не бачыць ніякай файлавай сістэмы. Значыць карыстальніка трэба папярэдзіць, што там нешта не так. Ansy пісаў (а): Калі пад fake-raid-1 маецца на ўвазе выкарыстанне убудаванага ў мацярынку адаптара, то гэты варыянт не коціць, бо:
- Мацярынка можа здохнуць разам з кантролерам, што ўжо было пару разоў на маёй памяці, і ад Вінды заставаліся толькі незагружабельные шрубы з дадзенымі, безадносна да RAID гэта страта многіх гадзін працоўнага часу на аднаўленне рабочай асяроддзя.
У 2014 годзе я спакойна Перенс дыскі ў Fake-Raid-1 з Asus Crosshair M2 (nForce), на Asus Crosshair V Formula-Z (AMD), кантролер на новай мацярынкі іх падхапіў як родныя аўтаматам. Я нават афігеў ад такога сэрвісу.
Ansy пісаў (а): [*] Я магу накаціць Linux на любую іншую мацярынку наўзамен (калі раптам) здохлымі (у адрозненне ад Windows) ці нават папрацаваць нейкі час з Live-носьбіта - калі будзе магчымасць прімонтіровать ЛЮБЫ з гэтай пары дыскаў з дадзенымі, BTRFS-RAID1 такое дазваляе, у адрозненне ад fake-raid.
Дыскі fake-raid-1 можна бязбольна чытаць і без raid-кантролера па адным. А вось пісаць на іх не трэба каб не зламаць сіметрыю дадзеных.
Ansy пісаў (а): [*] З стратай інфармацыі на вялікія (хуткім, але не гэтак надзейным) дыску гатовы змірыцца, бо застанецца "люстэрка" на дробным / надзейным, а ў "хвасце" прасторы, пакінутага ад RAID-1, размешчаная NTFS для межплатформных эксперыментаў, (бэкапируемых ў сетку) виртуалок (бо асноўны BTRFS-RAID1 з выкарыстаннем кампрэсіі, яны гэтага не любяць) і некрытычнага цяжкага кантэнту (часовыя файлы, слівы дадзеных з аднаўляных носьбітаў, дыстрыбутывы, даступныя з Сеткі, відэафайлы назірання і т. п.)
Пры ўмовах, што памрэ шруба, а не шруба + ФС. Я такое не так даўно перажыў - дадзеныя цэлыя, а вось метададзеныя, часопісы і блокі са структурай ФС накрыліся медным тазам. Выратавала толькі, што дадзеныя можна было аднавіць (павольна і ні разу неінтерактівных на іншы носьбіт) убудаваным функцыяналам. Аднаўленне 1 тэрабайт у мяне заняло 4 сутак. А ўся праблема ў тым, што на дыску паміраў кантролер (а не бэдблоки з'явіліся), і з-за яго глюкаў у каой момант ядро перапісала вобласць метададзеных на нармальным дыску. Fake-raid першапачаткова бы пазначыў збойных дыск, і не дапусціў бы такой фейла ядра.
І так, вы атрымаеце хуткасць працы павольнага шрубы як на запіс, так і на чытанне. Бо сістэма абуджае чытаць сектара напераменку з розных дыскаў.
У вашым жа выпадку я б проста rsync-ым синхронизовывал дадзеныя пры зменах на адным дыску. (Усяго-то патрэбен скрыпт, які будзе ствараць снапшоты на час сінхранізацыі, мантаваць з і сінхранізаваць з другім дыскам, пры наступлення падзей змены на ФС.)
Ansy пісаў (а): [*] працэсарныя магутнасць - справа апошняя, бо ў мяне канкрэтна каменьчык абсалютна некрытычна месца, як напэўна і ў большасці карыстальнікаў ПК. Апрацоўка абмену з дыскам і сціск абсалютна не напружваюць. [/ List]
Ну гэта дзе як. На даволі загружаных машынах (СКБД, канвертацыя відэа, 1С) - гэта можа выклікаць салідную страту ў прадукцыйнасці.
Ansy пісаў (а): PS Вось дарэчы яшчэ адзін магчымы касячок. Чаму падвойнымі мантаванне рутовых падзелу / dev / sda5 пры паказаным ніжэй змесціве / etc / fstab?
Таму, што ў вас розныя подтомов. А з улікам таго, што другі раз у вас прымацаваны да дырэкторыі / media // master, то я раблю выснову (а мог бы правесці сеанс празорлівасці 
), Што ваш лагін master, а змантаваных туды таму, што вы ў дэльфіне клікнулі па дыску з сістэмным подтомов.
Мантаваць подтомов на адным раздзеле можна
код: вылучыць усё
mount | grep sdc3 / dev / sdc3 on / type btrfs (rw, noatime, compress = lzo, space_cache, subvolid = 374, subvol = / @ Rosa_Fresh_2014.1_KDE4) / dev / sdc3 on / usr / local type btrfs (rw, noatime, compress = lzo, space_cache, subvolid = 263, subvol = / Common / USR_Local) / dev / sdc3 on / opt type btrfs (rw, noatime, compress = lzo, space_cache, subvolid = 262, subvol = / Common / OPT) cat / etc / fstab | grep subvol UUID = d83f82e6-a28f-4c4b-aa5d-43bea81b8b12 / btrfs noatime, nofail, subvol = @ Rosa_Fresh_2014.1_KDE4, compress = lzo 1 1 UUID = d83f82e6-a28f-4c4b-aa5d-43bea81b8b12 / opt btrfs noatime, nofail, subvol = Common / OPT, compress = lzo 1 1 UUID = d83f82e6-a28f-4c4b-aa5d-43bea81b8b12 / usr / local btrfs noatime, nofail, subvol = Common / USR_Local, compress = lzo 1 1 / dev / sda / home btrfs subvol = @ Rosa_Fresh_Home, compress = lzo 1 1 / dev / sda / mnt / Zone / Home / Old btrfs subvol = Home, compress = lzo 1 1 / dev / sda / mnt / Zone / Home / Common btrfs subvol = @ Common, compress = lzo 1 1 / dev / sda / mnt / Zone / Home / Cache btrfs subvol = @ Cache, compress = lzo 1 1
Чаму падвойнымі мантаванне рутовых падзелу / dev / sda5 пры паказаным ніжэй змесціве / etc / fstab?
