AdminTool AdminTool Proposals

[Michael_123]

Ich bin heute faul deshalb:

http://www.synology-forum.de/showthread.html?p=102732#post102732

 

[itari]

Ich bin heute faul deshalb:

http://www.synology-forum.de/showthread.html?p=102732#post102732

File-system-checks sind aber schon im AdminTool eingebaut:

Disks->File-System->Panel4-6

Itari

 

[Michael_123]

Da sagt er bei mir immer:

Synology> fsck.ext3 -nv /dev/`(egrep md2 /proc/diskstats || egrep 'sda3|hda3')|awk '$4>0{print $3}'`

Could this be a zero-length partition?

und:

Synology> fsck.ext3 -nv /dev/`(egrep md0 /proc/diskstats || egrep 'sda1|hda1')|awk '$4>0{print $3}'`

Could this be a zero-length partition?

----

Beim meinem Filesystem muss wohl etwas "Tieferes" zerschossen sein ?

Beim Runterfahren hängt er außerdem. Und in /var/log/messages steht:

May 27 16:26:13 kernel: EXT3-fs warning: maximal mount count reached, running e2fsck is recommended

Die Kiste läuft 24h durch.

 

[itari]

Mach das doch zur Probe auch noch mal richtig auf der Kommandozeile. Kann ja auch sein, dass mein Skript da ein Problem hat (bei mir geht das durch, aber man weiß ja nie).

Bei mir kommt z.B. heraus:

Synology> fsck.ext3 -nv /dev/`(egrep md0 /proc/diskstats || egrep 'sda1|hda1')|awk '$4>0{print $3}'`

Warning!  /dev/md0 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
1.39-Apr222009 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? no

Inode 263161 was part of the orphaned inode list.  IGNORED.
Inode 263162 was part of the orphaned inode list.  IGNORED.
Deleted inode 263165 has zero dtime.  Fix? no

Inode 263169 was part of the orphaned inode list.  IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -524809 -531492 -(536595--538539) -(538632--540671) -(540674--540704) -(540957--541088) -(541096--541194) -(541200--541486) -(541488--541549) -(541552--541588) -(541725--542017) -(542024--542064) -(542237--542719) -(542736--542758) -(543261--543299) -(543304--543518) -(543520--543538)
Fix? no

Free blocks count wrong (497882, counted=487593).
Fix? no

Inode bitmap differences:  -(263161--263162) -263165 -263169
Fix? no

Directories count wrong for group #16 (157, counted=155).
Fix? no

Free inodes count wrong (295862, counted=294710).
Fix? no


1.39-Apr222009: ********** WARNING: Filesystem still has errors **********


   15434 inodes used (4.96%)
     234 non-contiguous inodes (1.5%)
         # of inodes with ind/dind/tind blocks: 963/10/0
  124598 blocks used (20.02%)
       0 bad blocks
       1 large file

   13145 regular files
    1626 directories
      59 character device files
    1321 block device files
       0 fifos
       3 links
     421 symbolic links (421 fast symbolic links)
       1 socket
--------
   16576 files

Du siehst also auch, dass es auch Fehlermeldungen bei mir gibt ... welche sich dank des Journals nicht direkt auswirken (der fsck macht ja seine Prüfung ohne die Einsicht ins Journal). Zum Reparieren müsste ich das machen, was ich schon einmal vor langer Zeit gepostet hatte (Mod in der /etc/rc - ihr habt da ja eine Referenz drauf gemacht). Die Frage ist, ob sich die Reparatur wirklich lohnt ... sind ja nur ein paar Blöcke bgzw. Blockverweise, die da durch hängen ... also nicht wirklich was Schlimmes.

Itari

 

[Michael_123]

Wenn ich mich per root unter telnet einlogge und diese Zeile eingebe:

fsck.ext3 -nv /dev/`(egrep md0 /proc/diskstats || egrep 'sda1|hda1')|awk '$4>0{print $3}'`

Dann meldet er:

egrep: /proc/diskstats : No such file or directory

wenn ich dann:

mkdir /proc/diskstats

eingebe dann kommt komischerweise:

mkdir: cannot create directory '/proc/diskstats': No such file or directory

 

[itari]

Mach mal 'cat /proc/diskstats' und poste es hier

Itari

 

[Benares]

Dann mach ich das mal. Bei mir klappt

fsck.ext3 -nv /dev/`(egrep md0 /proc/diskstats || egrep 'sda1|hda1')|awk '$4>0{print $3}'`

auch nicht. Da kommt

e2fsck 1.41.3 (12-Oct-2008)
Warning!  /dev/md0 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
1.39-Aug252008: is cleanly umounted, 14652/311296 files, 127974/622480 blocks

oder ist das ok?

DS209> cat /proc/diskstats
   1    0 ram0 0 0 0 0 0 0 0 0 0 0 0
   1    1 ram1 0 0 0 0 0 0 0 0 0 0 0
   1    2 ram2 0 0 0 0 0 0 0 0 0 0 0
   1    3 ram3 0 0 0 0 0 0 0 0 0 0 0
   1    4 ram4 0 0 0 0 0 0 0 0 0 0 0
   1    5 ram5 0 0 0 0 0 0 0 0 0 0 0
   1    6 ram6 0 0 0 0 0 0 0 0 0 0 0
   1    7 ram7 0 0 0 0 0 0 0 0 0 0 0
   1    8 ram8 0 0 0 0 0 0 0 0 0 0 0
   1    9 ram9 0 0 0 0 0 0 0 0 0 0 0
   1   10 ram10 0 0 0 0 0 0 0 0 0 0 0
   1   11 ram11 0 0 0 0 0 0 0 0 0 0 0
   1   12 ram12 0 0 0 0 0 0 0 0 0 0 0
   1   13 ram13 0 0 0 0 0 0 0 0 0 0 0
   1   14 ram14 0 0 0 0 0 0 0 0 0 0 0
   1   15 ram15 0 0 0 0 0 0 0 0 0 0 0
   7    0 loop0 0 0 0 0 0 0 0 0 0 0 0
   7    1 loop1 0 0 0 0 0 0 0 0 0 0 0
   7    2 loop2 0 0 0 0 0 0 0 0 0 0 0
   7    3 loop3 0 0 0 0 0 0 0 0 0 0 0
   7    4 loop4 0 0 0 0 0 0 0 0 0 0 0
   7    5 loop5 0 0 0 0 0 0 0 0 0 0 0
   7    6 loop6 0 0 0 0 0 0 0 0 0 0 0
   7    7 loop7 0 0 0 0 0 0 0 0 0 0 0
   8    0 sda 6118 7147 162945 9844 1200 3956 42280 11921 0 11616 21760
   8    1 sda1 9998 151450 5037 40296
   8    2 sda2 2 16 0 0
   8    3 sda3 241 8056 133 1064
   8   16 sdb 6040 6708 149907 11441 1199 3957 42280 14686 0 14290 26120
   8   17 sdb1 9333 142162 5037 40296
   8   18 sdb2 5 40 0 0
   8   19 sdb3 386 4282 133 1064
   9    0 md0 19329 0 293596 0 4941 0 39528 0 0 0 0
   9    1 md1 5 0 40 0 0 0 0 0 0 0 0
   9    2 md2 579 0 12114 0 115 0 920 0 0 0 0

Gruß
Benares

 

[itari]

Bei dir müssten gehen:

fsck.ext3 -nv /dev/md0 und fsck.ext3 -nv /dev/md2

Ob da allerdings was Schönes bei heraus kommt, hatte ich ja schon weiter oben gepostet, weil das Journal nicht verwendet wird. Die Option -nv sorgt dafür, dass nichts 'repariert' wird, sondern nur eine Diagnose-Anzeige erfolgt. Kannst also bedenkenlos machen.

Ohne die Option -nv wird allerdings auch nur sinnvoll repariert, wenn das Dateisystem nicht im Gebrauch ist (umounted). Das geht bekanntlich bei der /dev/md0 nicht, weil da das System drauf ist.

Ein reparierender fsck kann schon so 20 Minuten bis mehrere Stunden dauern ... Er sollte eigentlich sowieso beim Booten gemacht werden. Bei manchen dauert das Booten ja auch etwas länger wegen dieser Prozedur. Da immer die Gefahr besteht, dass man sich die Dateisysteme damit ruiniert, sollte man es eigentlich immer nur nach einem Backup gemacht werden.

Itari

 

[Michael_123]

Mach mal 'cat /proc/diskstats' und poste es hier

Itari

cat: /proc/diskstats: No such file or directory

 

[Michael_123]

Ein reparierender fsck kann schon so 20 Minuten bis mehrere Stunden dauern ... Er sollte eigentlich sowieso beim Booten gemacht werden. Bei manchen dauert das Booten ja auch etwas länger wegen dieser Prozedur. Da immer die Gefahr besteht, dass man sich die Dateisysteme damit ruiniert, sollte man es eigentlich immer nur nach einem Backup gemacht werden.

Itari

Wie kommt es, das das so kompliziert, fehleranfällig und unsicher ist ?

Ich will ja nichts sagen aber bei NTFS ist es einfacher.

 

[itari]

Wie kommt es, das das so kompliziert, fehleranfällig und unsicher ist ?

Ich will ja nichts sagen aber bei NTFS ist es einfacher.

So Bemerkungen liebe ich ... wer sagt dir denn, dass das nicht bei NTFS ähnlich kompliziert und unsicher ist? Ich würde dir da die gleichen Ratschläge geben.

Itari

 

[Michael_123]

So Bemerkungen liebe ich ... wer sagt dir denn, dass das nicht bei NTFS ähnlich kompliziert und unsicher ist? Ich würde dir da die gleichen Ratschläge geben.

Itari

Nun. Ich habe noch nie erlebt oder gehört dass ein Dateisystemcheck bei NTFS das Filesystem zerschossen hätte.
Praktisch gesehen ist darauf Verlass. Vor irgendwelchen theoretischen Bedenken weiß ich nichts, da ich davon keine Ahnung habe.
Ich kenne nur die Praxis und das ist bei NTFS so, dass dieses problemlos repariert werden kann und die Bedienung des Tools zum Reparieren ist einfach für jeden zu handhaben.
Oder nicht ?
Bei ext2/3 scheint es so viele "wenn und abers" zu geben, dass dort die Empfehlung heissen muss:
Der Filesystemcheck geht manchmal, aber reparieren lassen lieber nicht. Damit machst du öfters mehr kaputt als heil.
Lebe mit den Fehlern im Filesystem, denn eine Reparatur ist zu gefährlich.
So gehst du doch auch vor.

 

[itari]

Ein fsck für ext2/3 ist genauso sicher wie ein Dateisystem-Check/Repair für NTFS. Es gibt keine wenns oder abers. Es ist nur meine persönliche Gepflogenheit, immer Prozeduren, die ein minimales (aber eben auch ein Risiko) enthalten, abzusichern. Deswegen würde ich es dir auch immer bei einem Windows-System raten. Überlege mal was passieren würde, wenn du während der Reparatur den Strom ausmachen würdest. Da ja beide ein journalisierendes File-System verwenden, wären sie schwerlich korrupt zu bekommen. Aber sollte es mal sein, dann ist die Kacke am dampfen, wenn man keine Sicherung hat. Deswegen gehört es sich, dass man so etwas auch empfiehlt.

Alles weitere gehört in den Bereich der Fantasie.

Itari

 

[Michael_123]

Ein fsck für ext2/3 ist genauso sicher wie ein Dateisystem-Check/Repair für NTFS. Es gibt keine wenns oder abers. Es ist nur meine persönliche Gepflogenheit, immer Prozeduren, die ein minimales (aber eben auch ein Risiko) enthalten, abzusichern. Deswegen würde ich es dir auch immer bei einem Windows-System raten. Überlege mal was passieren würde, wenn du während der Reparatur den Strom ausmachen würdest. Da ja beide ein journalisierendes File-System verwenden, wären sie schwerlich korrupt zu bekommen. Aber sollte es mal sein, dann ist die Kacke am dampfen, wenn man keine Sicherung hat. Deswegen gehört es sich, dass man so etwas auch empfiehlt.

Alles weitere gehört in den Bereich der Fantasie.

Itari

Schön und gut.
Und wie kann ich jetzt das Filesystem meiner Synology testen und reparieren lassen ?
Falls dabei der Strom ausfällt, ich außerdem Pech habe und kein Backup dann werde ich mich bei niemandem beschweren. Dann habe ich selbst Schuld.
Oder noch besser: Ich gebe dir Zugriff auf meine Box und du machst es für mich während ich das Risiko übernehme.
Das nur um damit mal eine kreative Lösung vorzuschlagen. Du wirst doch nicht dem zustimmen, oder ?

 

[thedude]

Strom ausschalten ist auch bei einem journalisierenden File-System wie es NTFS und ext3 sind, nicht gut. Das Journal ist ja auch nur für die Metadaten und nicht für die Daten selbst.

Mich würde mal interessieren wie Synology gedenkt mit den Filechecks umzugehen. Ich mein früher oder später tauchen bei allen DS die Warnungen beim Booten bzw. mounten auf. Gibt es da keine offiziellen Weg?

Gruß
Dude

 

[itari]

Strom ausschalten ist auch bei einem journalisierenden File-System wie es NTFS und ext3 sind, nicht gut. Das Journal ist ja auch nur für die Metadaten und nicht für die Daten selbst.

Mich würde mal interessieren wie Synology gedenkt mit den Filechecks umzugehen. Ich mein früher oder später tauchen bei allen DS die Warnungen beim Booten bzw. mounten auf. Gibt es da keine offiziellen Weg?

Selbstverständlich geht es bei einem File-System-Check immer nur um die "Metadaten". Das ist aber bei allen hier zur Diskussion stehenden Dateisystemen so.

Über Filechecks ist mir nicht wirklich was bekannt; du meinst sicherlich File-System-Checks. Du kannst hierzu die /etc/rc anschauen. Dort wird für jedes (zu mountende) Dateisystem eine File-System-Check dahingegend ausgeführt, festzustellen, ob das Dateisystem auch ordentlich umounted ist:

	FSCK="/sbin/fsck.${FS} -nq"

	DoMount=1

	IsClean=`${FSCK} $ThisDevice | grep "is cleanly umounted"`
	if [ -n "$IsClean"  ]; then
		echo "$ThisDevice. Clean. "
		IsClean=1
	else
		IsClean=0
	fi

Sobald festgestellt worden ist, dass es nicht sauber ist (also IsClean=0), wird etwas später dann ein 'quotacheck'-run durchgeführt (welche intensiver ist als ein normaler fsck, da er weitere Aufgaben enthält):

	if [ $IsClean -eq 0 ]; then
		DoQuotaCheck=1
	fi

	if [ -f ${ThisVolume}/.needquotacheck ]; then
		echo "Get $ThisVolume/.needquotacheck"
		DoQuotaCheck=1
	fi

	if [ $DoQuotaCheck -eq 1 ]; then
		echo "Quotacheck on $ThisVolume."
		/sbin/quotacheck -g -u -F vfsv0 $ThisVolume

		mount -o remount,usrquota,grpquota${MOUNT_OPT} $ThisVolume
		rm -f ${ThisVolume}/.needquotacheck
	fi

Das ist auch die Ecke, wo es so lange dauert beim Booten, wenn du das mit dem IPKG-mount vergessen hast zu umounten ... Nach einem 'quotacheck' ist alles ok mit dem Dateisystem. Das wäre nun jetzt der 'offizielle' Weg. Alle weiteren Datei-System-Inkonsistenzen sind nicht wirklich von Bedeutung. Du kannst sie präventiv mit meinem Mod der /etc/rc schön färben, aber notwendig wäre das nicht.

Und ja, selbstverständlich können und sollten wir einmal die Synology-Entwickler danach fragen, warum keine explizite File-System-Check-Funktionalität im DS-Manager eingebaut ist. Und warum bei einem embedded Linux es keinen init s-Mode gibt, bei dem man auch das Betriebssystem residierende Datei-System nicht reparieren kann. Man könnte ja wie beim Booten, einen fsck durchführen, solange der Kernel und die Busybox (init) im RAM liegen. Aber vermutlich wird das eh schon gemacht ... hab mich nie mit der Boot-Phase wirklich auseinander gesetzt.

Itari

 

[itari]

Schön und gut.
Und wie kann ich jetzt das Filesystem meiner Synology testen und reparieren lassen ?

Normalerweise wird das beim Booten sowieso gemacht.

Falls dabei der Strom ausfällt, ich außerdem Pech habe und kein Backup dann werde ich mich bei niemandem beschweren. Dann habe ich selbst Schuld.
Oder noch besser: Ich gebe dir Zugriff auf meine Box und du machst es für mich während ich das Risiko übernehme.
Das nur um damit mal eine kreative Lösung vorzuschlagen. Du wirst doch nicht dem zustimmen, oder ?

Selbstverständlich kann man mich mieten .... um mal auf deinen 'kreativen' Vorschlag einzugehen.

Itari