Oggi, mentre smanettavo con uno script per fare un backup del mio fido NAS Synology DS413j sulla mia altrettanto fida Time Capsule, ho scoperto nei log qualche segno di squilibrio del filesystem. Ho prontamente cercato nell’interfaccia del nuovissimo DSM 5.0 qualche funzionalità per lanciare un fsck ma, ahimè, pare che l’OS Synology sia incredibilmente carente di tale fondamentale funzione (!).
In ogni caso, non è un grosso problema, dato che è sempre possibile abilitare l’accesso al NAS tramite SSH/telnet, potendo così procedere ad un fsck manuale. Ovviamente, però, è necessario smontare prima il filesystem, cosa che a sua volta richiede l’arresto di tutti i servizi in esecuzione. Ora, l’OS Synology non rispetta molto il Linux FHS, per cui capire come fare ciò non è esattamente immediato. Fortunatamente basta googlare un po’ per trovare suggerimenti di chi ha già avuto questo problema, ma… nessuno pare avere già fatto ciò con il DSM 5 :(. Ecco come ne sono uscito.
Il primo passo consiste nell’abilitare l’accesso al NAS tramite telnet. SSH non va bene, perché verrà killato brutalmente dal primo comando che lanceremo. In realtà, anche telnetd farà la stessa fine, ma almeno la sessione in uso rimarrà attiva, permettendoci di andare avanti. Fatto ciò, ce la caviamo con poco:
slackberry ~ # telnet 10.0.0.245 Trying 10.0.0.245... Connected to 10.0.0.245. Escape character is '^]'. SukkoNAS login: root Password: SukkoNAS> syno_poweroff_task synologrotated stop/waiting nmbd stop/waiting synobackupd stop/waiting webdav-httpd-ssl stop/waiting afpd stop/waiting smbd stop/waiting synomkflvd stop/waiting initctl: Unknown instance: sshd stop/waiting ntpd stop/waiting crond stop/waiting syslog-acc stop/waiting cnid_metad stop/waiting webdav-httpd stop/waiting synomkthumbd stop/waiting nfsd-adapter stop/waiting httpd-user stop/waiting img_backupd stop/waiting SukkoNAS> mdadm --assemble --scan mdadm: /dev/md/2 has been started with 4 drives. SukkoNAS> e2fsck -fv /dev/md2 e2fsck 1.42.6 (21-Sep-2012) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity /lost+found not found. Create? yes Pass 4: Checking reference counts Pass 5: Checking group summary information 1.41.12-2668: ***** FILE SYSTEM WAS MODIFIED ***** 653213 inodes used (0.12%, out of 548544512) 10604 non-contiguous files (1.6%) 189 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 650056/2212/44 425317438 blocks used (19.38%, out of 2194158192) 0 bad blocks 40 large files 574022 regular files 77959 directories 0 character device files 0 block device files 3 fifos 7 links 1211 symbolic links (880 fast symbolic links) 8 sockets ------------ 653210 files SukkoNAS> reboot Broadcast message from root@SukkoNAS (/dev/ttyp0) at 20:49 ... The system is going down for reboot NOW! SukkoNAS> Connection closed by foreign host. slackberry ~ #
Non c’è molto da dire, sono tutti comandi abbastanza basilari, a parte il primo, che è un comando non documentato Synology che serve a fermare tutti i servizi, e che quindi fa la maggior parte del “lavoro sporco” che ci serve (mettendoci anche un discreto tempo…). Peccato che smonti anche la partizione dei dati e fermi il device software RAID corrispondente, che va quindi riassemblato (eventualmente conviene fare un cat /proc/mdstat come primissimo comando, per capire come riassemblare il RAID a mano se la modalità automatica non dovesse funzionare), e quindi si può procedere con il vero e proprio fsck, per concludere con un reboot dell’intero NAS, in modo da tornare alla situazione normale.
Ci tengo a sottolineare che nel mio setup (RAID 5 puro) non viene utilizzato LVM. In caso contrario, un vgchange -ay qua o là avrebbe probabilmente aiutato.