Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a CentOS server using raid.

The /proc/partitions contains:

major minor  #blocks  name

   8     0  976762584 sda
   8     1     104391 sda1
   8     2  921600855 sda2
   8     3   55054755 sda3
   8    16  976762584 sdb
   8    17  921600823 sdb1
   8    18   55159177 sdb2
   8    32  976762584 sdc
   8    33  921600823 sdc1
   8    34   55159177 sdc2
   8    48  976762584 sdd
   8    49  921600823 sdd1
   8    50   55159177 sdd2
   8    64  976762584 sde
   8    65  921600823 sde1
   8    66   55159177 sde2
 253     0  270303232 dm-0
 253     1    5341184 dm-1
   9     0 4608002816 md0

/etc/fstabs contains:

/dev/VolGroup00/LogVol00   /             ext3    defaults,usrquota,grpquota      1 1
/dev/md0                   /home         ext3    defaults,usrquota,grpquota      1 2
LABEL=/boot                /boot         ext3    defaults        1 2
tmpfs                      /dev/shm      tmpfs   defaults        0 0
devpts                     /dev/pts      devpts  gid=5,mode=620  0 0
sysfs                      /sys          sysfs   defaults        0 0
proc                       /proc         proc    defaults        0 0
/dev/VolGroup00/LogVol01   swap          swap    defaults        0 0

mdadm --detail /dev/md0 produces:

/dev/md0:
        Version : 0.90
  Creation Time : Tue Feb 28 14:00:14 2012
     Raid Level : raid0
     Array Size : 4608002816 (4394.53 GiB 4718.59 GB)
   Raid Devices : 5
  Total Devices : 5
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Feb 28 14:00:14 2012
          State : clean
 Active Devices : 5
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 256K

           UUID : a09e9fd0:62b06654:b224f2d2:0e34ad8f
         Events : 0.1

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1
       3       8       49        3      active sync   /dev/sdd1
       4       8       65        4      active sync   /dev/sde1

/etc/mdadm.conf contains:

# mdadm.conf written out by anaconda
DEVICE partitions
MAILADDR root
ARRAY /dev/md0 super-minor=0
#ARRAY /dev/md0 level=raid0 num-devices=5 UUID=a09e9fd0:62b06654:b224f2d2:0e34ad8f

From what I can see the hard drives OK.

Yet I have run fsck -yfC /dev/md0 and it does:

Pass 1: Checking inodes, blocks and sizes

Running additional passes to resolve blocks claimed by more than one inode ....
Pass  1B:  Rescanning for multiply-claimed blocks.

When I mount the device mount /dev/md0 it mounts.

As soon as any activity tries to write to the /dev/md0 or directory /home it says the files system is not clean and mounts it is read only mode.

Then the system stops working.

share|improve this question

closed as off-topic by psusi, slm Apr 24 at 3:45

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – psusi, slm
If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Double post: superuser.com/questions/591458/… –  Spack May 4 '13 at 15:34
1  
What's the content of /proc/mdstat? –  Spack May 4 '13 at 16:09
1  
What do you mean by "write to the /dev/md0"? Anything different from "write to directory /home"? –  Hauke Laging May 4 '13 at 16:09
1  
What's the file system on /dev/md0? I thought you'd run fsck against an actual file system on the device? –  slm May 4 '13 at 16:51
1  
Check dmesg for error details. –  psusi May 4 '13 at 17:11

1 Answer 1

In order to make testing easier (fsck probably takes an eternity on such huge volumes) you could create a helper DM volume which is completely mapped to /dev/md0. Then you create a snapshot of this helper volume. This snapshot can be written to without /dev/md0 being touched.

My idea is that you mount the volume with ext2 instead. Would be interesting whether the error disappears then.

If you want to give that a try but don't know how to handle the snapshot I can provide the details.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.