On Thu, Sep 10, 2009 at 01:01:42PM -0400, Diego Remolina wrote: >> Did you use the same file system _type_? > > Yep, the file system was ext3 in both cases. I was originally using ext4 > and thought the original problem was related to ext4 and redhat having > the very early version, so I backed up the data, reformatted ext3, > restored the data and the problem was still there. I then backed down to > the older kernel and have no problems. > > [r...@phys-file01 ~]# mount | grep drbd > /dev/drbd0 on /export/data type ext3 (rw,user_xattr,acl,usrquota,grpquota) > /dev/drbd1 on /export/scratch type ext3 > (rw,user_xattr,acl,usrquota,grpquota) > > [r...@phys-file01 ~]# mount | grep slash > /dev/mapper/VolGroup01-slash on / type ext3 (rw) > > [r...@phys-file01 export]# ls -l /export/test/ > total 10264 > -rw------- 1 dr126 2626 7179 Sep 10 09:36 Diego-File.odt > -rw------- 1 dr126 2626 10485760 Sep 10 09:35 testfile > > So as you can see, the Diego-File.odt was written correctly to > /export/test/ from a client using nfs4. > > [r...@phys-file01 export]# grep test /etc/exports > /export/test gss/krb5(rw,sync,root_squash,nohide) > > A sample of a file with the broken permissions and time stamp: > > [r...@phys-file01 dr126]# ls -l KDE.startkde.bC4799 > --w-rwxrwt 1 dr126 2626 0 Jan 18 2038 KDE.startkde.bC4799
nice one. Ok, so then add an other fresh and new DRBD running on that kernel, and do a fresh mkfs.ext3 on it, and export it. just to prove that it is NOT drbd. then compare tune2fs and mount options, and clients, maybe update clients as well, and see if you find a client that works... Really. It just cannot be the block layer. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. _______________________________________________ drbd-user mailing list [email protected] http://lists.linbit.com/mailman/listinfo/drbd-user
