Latest working kernel version: 2.6.26 Earliest failing kernel version: 2.6.27 Distribution: Debian - Kernel is compiled by myself Hardware Environment: x86_64, 5GB RAM, S/W RAID-5 Software Environment: Debian testing Problem Description: After compiling 2.6.27 and booting to it there were a lot of errors with file operations at the root filesystem. All of them were complains about Read-only filesystem. It turned out that with 2.6.27 I can create and remove files, change their contents but I can't change the file permissions or file times. chown, tar and other commands gave this kind of errors. strace showed EROFS return codes from various system calls. This is happening only at the / filesystem (XFS). Other XFS filesystems worked OK. Tried remounting it ro and then rw but no change. Also, after booting to 2.6.27 and back to 2.6.26 and running xfs_check/xfs_repair, 308 files were placed in /lost+found. xfs_repair was run under 2.6.26. Them I booted back to 2.6.27 and return xfs_check on / and it showed more errors. I've not rerun xfs_repair on / since. Configuration is XFS over software raid5 with 4 disks. Mount options from /proc/mounts: /dev/md/6 / xfs rw,noatime,attr2,nobarrier,sunit=128,swidth=256,noquota 0 0 /dev/md/5 /home xfs rw,noatime,attr2,nobarrier,sunit=128,swidth=256,noquota 0 0 /dev/md/6 gives the RO errors, while /dev/md/5 works very well. While in 2.6.27 I tried mounting /dev/md/6 (/) to another place (/mnt/1) too and it had the same behavior over there. 2.6.26 still works very well. Dmesg gave no errors or noticed of XFS for auto-remounting / read-only. Is there anything more I can try? Kernel is custom made - not the official Debian. Steps to reproduce: Boot to 2.6.27. Most probably happens only to me (?). From 2.6.26: # xfs_info / meta-data=/dev/md/6 isize=256 agcount=24, agsize=610480 blks = sectsz=4096 attr=2 data = bsize=4096 blocks=14651184, imaxpct=25 = sunit=16 swidth=32 blks naming =version 2 bsize=4096 log =internal bsize=4096 blocks=4769, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=131072 blocks=0, rtextents=0 # xfs_info /home meta-data=/dev/md/5 isize=512 agcount=24, agsize=1220688 blks = sectsz=4096 attr=2 data = bsize=4096 blocks=29296464, imaxpct=25 = sunit=16 swidth=32 blks naming =version 2 bsize=4096 log =internal bsize=4096 blocks=9536, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=131072 blocks=0, rtextents=0
This is probably the same bug Chrstoph just sent a patch for: [PATCH] fix remount rw with unrecognized options When we skip unrecognized options in xfs_fs_remount we should just break out of the switch and not return because otherwise we may skip clearing the xfs-internal read-only flag. This will only show up on some operations like touch because most read-only checks are done by the VFS which things this filesystem is r/w. Eventually we should replace the XFS read-only flag with a helper that always checks the VFS flag to make sure they can never get out of sync. Bug reported and fix verified by Marcel Beister on #xfs. Signed-off-by: Christoph Hellwig <hch@lst.de> Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2008-10-11 00:59:04.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2008-10-11 00:59:35.000000000 +0200 @@ -1218,7 +1218,7 @@ xfs_fs_remount( "XFS: mount option \"%s\" not supported for remount\n", p); return -EINVAL; #else - return 0; + break; #endif } } Can you try it? Thanks, -Eric
Yes. That fixed the 'Read-only' problem. Thanks a lot!