rw ist ro !?!

Hi,

schaut euch das mal an: komisches Sache oder?

Code:
root@mini:~# rm /tmp/mutt-mini-1000-5551-
rm: cannot remove `/tmp/mutt-mini-1000-5551-': Read-only file system
root@mini:~# mount | grep sda3
/dev/sda3 on / type ext4 (rw,errors=remount-ro)
root@mini:~# mount -o remount /dev/sda3
mount: cannot remount block device /dev/sda3 read-write, is write-protected
root@mini:~#

Gibt irgendwie nicht ganz so viel Sinn... Das Filesystem ist RW gemountet (das sagt jedenfalls mount), ein schreiben ist aber nicht möglich.

Hat jemand ne Idee?

cu
serow
 
Sagt das Kernel Log etwas ueber die Platte (also z.b. wiederholte DMA Timeouts) oder sind evtl. einfach keine Inodes mehr verfuegbar?
 
Hi,

ich konnte keine Auffälligkeiten finden in den Logs. Wie würde man das herausfinden wenn keine Inodes mehr da sind?

Das sagt mir dumpe2fs über das ext4:

Code:
dumpe2fs 1.41.9 (22-Aug-2009)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          ebec08b0-cd85-4b2b-8541-06496dad874b
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              5767168
Block count:              23046875
Reserved block count:     1152343
Free blocks:              17252538
Free inodes:              5365995
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1018
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Tue Nov 17 21:47:16 2009
Last mount time:          Mon Feb 15 10:32:38 2010
Last write time:          Mon Feb 15 10:30:51 2010
Mount count:              1
Maximum mount count:      20
Last checked:             Mon Feb 15 10:30:51 2010
Check interval:           15552000 (6 months)
Next check after:         Sat Aug 14 11:30:51 2010
Lifetime writes:          130 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       173953
Default directory hash:   half_md4
Directory Hash Seed:      5db5bddc-fba3-4569-b726-3ee44c475a51
Journal backup:           inode blocks
Journal size:             128M

Was zZ auch häufig passiert ist, dass ich nach einem reboot erstmal ein e2fsck -f /dev/sda3 auf das Dateisystem ausführen muss damit er hochfährt. Scheint irgendwie mit dem Standby-Modus zusammenzuhängen vermute ich.

EDIT: Ach, dumpe2fs sagts mir ja:

Code:
Free inodes:              5365995

cu
serow
 
Hmm, ja ich hab grad noch etwas drueber nachgedacht und daran kanns eigentlich auch nicht gelegen haben (weil der Kernel dann sagen wuerde "kein Platz mehr" statt "nur lesbar"). Hast du mal mit
Code:
smartctl -A /dev/sda
geguckt, ob die Platte hardwaretechnisch noch in Ordnung ist? (Stichwort hier: Reallocated Block count und Load cycles)
 
Hi,

eigentlich auch wieder wahr ^^

Mit smartctl steh ich noch auf Kriegsfuß. Kann den Output nicht interpretieren :D

Code:
mathias@mini:~$ sudo smartctl -A /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   100   046    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   030    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0003   100   100   025    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       490
  5 Reallocated_Sector_Ct   0x0033   100   100   024    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   100   100   047    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   019    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       3973
 10 Spin_Retry_Count        0x0013   100   100   020    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       476
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       72
193 Load_Cycle_Count        0x0032   098   098   000    Old_age   Always       -       40757
194 Temperature_Celsius     0x0022   100   090   000    Old_age   Always       -       47 (Lifetime Min/Max 18/62)
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       0
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   253   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000f   100   100   060    Pre-fail  Always       -       0
203 Run_Out_Cancel          0x0002   100   100   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x003e   200   200   000    Old_age   Always       -       0

mathias@mini:~$

Aber vllt kannst du mir da helfen ;)

cu
serow
 
Hmm, sieht nicht schlimm aus. Kritisch wirds erst, wenn die Attribute unter den Grenzwert fallen, also sollte da noch alles in Ordnung sein. Das einzige, was mir noch einfaellt, waeren defekte Hardwarebloecke, die von Smart noch nicht gefunden wurden oder ein defektes Dateisystem. Kaputte Hardwarebloecke findet man mit badblocks(8), allerdings solltest du da einiges an Zeit mitbringen und die Manpage aufmerksam lesen, manche von den Tests, die badblocks benutzt zerstoeren naemlich Daten auf dem Datentraeger. Daher wuerde ich mal empfehlen, mit
Code:
fsck -yfc /dev/sda
einen tieferen FS-Test zu erzwingen, allerdings dauert das auch einige Zeit.
 
Viele Distributionen mounten /tmp als seperates SquashFS oder tmpfs, meistens noexec. Danach solltest du auch mal schauen.
 
Hi,

das hatte ich garnicht gefunden... Warum auch immer ... Danke jedenfalls. Scheinbar kann man da erstmal recht wenig machen.

cu
serow
 
Zurück
Oben