Podążaj za instrukcjami w poniższym filmie, aby zobaczyć, jak zainstalować naszą stronę jako aplikację internetową na ekranie głównym swojego urządzenia.
Informacja: Ta funkcja może nie być dostępna w niektórych przeglądarkach.
Używasz przestarzałej przeglądarki. Może ona nie wyświetlać poprawnie tej lub innych stron internetowych. Powinieneś zaktualizować swoją przeglądarkę lub użyć alternatywnej przeglądarki.
Cześć, na QNAP TS-453D zmigrowałem macierz RAID 1 do RAID 5 i zauważyłem nową opcję: BBM (Bad Block Management), ale ze stanem nieaktywna. Jak doczytałem się w dokumentacji, opcja ta nie jest obsługiwana dla macierzy zmigrowanych z RAID 1. Ponieważ dokumentacja mówi bardzo lakonicznie o tym trybie, a i Internety niewiele więcej, mam kilka pytań z tym związanych:
1. W kontekście toczonych gdzieniegdzie dyskusji, że RAID 5 dla dużych dysków nie powinien być stosowany, m.in. ze względu na duże ryzyko wystąpienia pojedynczych, błędnych bloków szczególnie przy odbudowie RAID, uniemożliwiających poprawną odbudową macierzy, włączenie tej funkcji wydaje się bardzo istotne... Czy tak jest w rzeczywistości?
2. Wg dokumentacji nie ma możliwości włączenia tej opcji na istniejącej grupie - trzeba utworzyć grupę RAID 5 na nowo. Czy może jednak istnieją nieoficjalne sposoby na włączenie tej funkcjonalności na istniejącej grupie RAID, bez utraty jej zawartości? Mam backup danych na zewnętrznym nośniku i w chmurze, więc ewentualna utrata nie jest problemem, ale chciałbym uniknąć tworzenia grupy RAID na nowo i odtwarzania wszystkich danych i ustawień, jeżeli to możliwe.
3. Czy QNAP TS-453D z najnowszym QTS 5 obsługuje tą funkcjonalność (w moim przypadku, obecnie zainstalowany jest QTS 5.0.1.2248)? Wg dokumentacji tylko TS-x53 i TX-x53A z serii 53 są wymienione jako kompatybilne modele, co wydaje mi się trochę dziwne...
Szanowny kolego @pigers, chyba nie przeczytałeś ze zrozumieniem. Wersja systemu na moim QNAP-ie nie ma na tym etapie najmniejszego znaczenia, ponieważ nie pytam o to dlaczego coś mi nie działa, tylko czy ma szansę zadziałać, ponieważ dokumentacja jest w tym przypadku niejednoznaczna. Ziółka na uspokojenie proponuję w to niedzielne popołudnie... Pozdrawiam. PS: Uzupełniłem szczegółowo informację w oryginalnym wpisie.
@Silas Mariusz, właśnie do tej informacji się odnosiłem - niewiele jest w niej konkretów, stąd liczę, że może dowiem się czegoś więcej na forum.
@Czarek - a czy pomyślałeś o tym ze ktoś czytając to za miesiąc, pół roku - będzie wiedział jaka to była wersja w Twoim wypadku ? Zdecydowanie nie!
Co do reszty posta nie mam zastrzeżeń - pozdrawiam znad miski ramenu :*
BBM appears to be QNAP's name for mdraid's "bad block log". Without a bad block log, when any block on a device fails during RAID operations, that device is booted out of the array. If the array was already degraded with no further redundancy, this results in complete loss of data on the array without very time-intensive procedures to recover things. With a bad block log enabled, mdraid keeps track of block failures, and if a block ever fails when the array has no redundancy, it knows that only that block is bad. This makes array rebuilds (esp. on RAID 5) much safer because at that point the array is already degraded, and without the bad block log, any read failure during the rebuild results in complete failure of the array; with the bad block log, you'll only lose files affected by the bad block log. Of course, you should have backups, but restoring a few files from backup is much faster than restoring the entire array.
schumaku, you ask about how this interacts with modern disks that take care of sectors with read/write issues. Typically, if these devices experience an error during WRITE (including with checking the data was properly written), they will immediately re-map that sector to the spare set. Similarly, I believe they often remap sectors that have previously experienced a read error the next time they are written (though it's possible they don't if the subsequent write/check succeeds?). However, at the time of a read error, there's no way to get the data for that sector. The bad block log allows mdraid to act like a normal disk and just return a "**, I can't read that" to the OS (or, if you have redundancy, it'll grab it from another disk and rewrite it to the failing disk, causing the sectors to be remapped), vs failing the device out of the array entirely.
The bad block log is a somewhat (maybe 2014 in the mainline kernel? I forget) recent feature, and wasn't available in qnap's original builds. It's now supported at least at the kernel/mdraid level in all qnap firmwares I think. However, generally you create a RAID array with 'mdadm', and the version of mdadm that qnap ships in a number of the firmware builds doesn't support the bad block log. If your NAS ships with a supported version of mdadm, I think the default is supposed to be to create all arrays with a bad block log, though many of ours here have arrays that were set up before this feature was added, and I haven't seen any indication of them being automatically upgraded.
I don't know offhand of any ways to check bad block log presence from the QNAP web interface. However, if you are willing to log in via ssh, you can do the following:
1. Figure out the name of your data RAID device by running
Kod:
cat /proc/mdstat
Typically, it will be `/dev/md0`, but your configuration may vary.
2.
Kod:
cat /sys/block/md0/md/qnap_bbm
will return 1 if the bad block log is enabled, and 0 otherwise.
If your system has an mdadm that supports the bad block log, you can also use
Kod:
mdadm --examine /dev/sda3
(or substitute another relevant data partition in place of sda3) and it will have a line that shows something like "Bad Block Log : 512 entries available at offset -8 sectors". On my systems, some have version (`mdadm --version`) 2.6.x, which doesn't support it, while some have version 3.3, which does. I'm not sure exactly where the cutoff was, but if you scp the mdadm to another unix machine with `strings` installed, and run
Kod:
strings /tmp/mdadm | grep bbl
you'll get some output if your mdadm supports the bad block log.
If you want to enable the bad block log on a RAID device for which it's not currently enabled, the procedure (again via an ssh login) is roughly the following:
0. This requires a copy of mdadm that supports the bad block log. I use one that I ended up building from source with QDK or something, but you might also be able to copy one from a newer firmware or something? I did this a long time ago, so I don't actually remember how to do it.
1. stop services using the data device. Sometimes it can be tricky to get them all; usually at least the file servers, and my NASes seem to usually have mysqld and mytranscodesvr running. Sometimes I stop everything and still just have to try like 6 times (often rebooting in between) to get things to work. Starting some operation from the gui that requires services to be stopped might get the gui to do all the hard work for you here, but might leave you in a state that doesn't work for other reasons?
2.
Kod:
umount /dev/md0
to unmount the filesystem. You may have to return to step 1 to find more missing items. Obviously use *your* data device if it's not `/dev/md0` (that's going to apply throughout, so I'm not going to keep repeating it).
2a. Some newer QNAP setups use lvm to do fancy thin volume management on top of mdraid; if your system does this, you'll need to stop that, which is something vaguely like
Kod:
dmsetup ls
dmsetup remove cachedev1
vgchange -an vg1
to re-start the RAID and add bad block logs to all devices. Note that I've stored my custom-built, upgraded version of mdadm at /mnt/HDA_ROOT; if your mdadm supports this out of the box, you can just use `mdadm` instead of the full path. Also note that here I'm putting together `/dev/md0` from 6 partitions (`/dev/sda3`, etc) which may not be exactly your operation.
5. The easiest way to get things back into normal operating state (services running and such) is probably to reboot. The bad block log should stick around, though I think I've seen that it doesn't always get added to new disks when you swap them out, so you may have to repeat this after you add disks.
