On Jul 05, 2007 15:34 +0200, Bernd Schubert wrote: > on the mgs node e2fsck-1.39.cfs8 shows this: > > e2fsck 1.39.cfs8 (7-Apr-2007) > lustre-MDT0000: recovering journal > Clearing orphaned inode 26502799 (uid=1012, gid=100, mode=0100644, size=0) > Clearing orphaned inode 26501309 (uid=1012, gid=100, mode=0100644, size=0) > Clearing orphaned inode 26500161 (uid=1012, gid=100, mode=0100644, size=0) > Clearing orphaned inode 26499062 (uid=1012, gid=100, mode=0100644, size=0) > Clearing orphaned inode 26497822 (uid=1012, gid=100, mode=0100644, size=0) > Clearing orphaned inode 26497454 (uid=1012, gid=100, mode=0100644, size=0) > Clearing orphaned inode 26470885 (uid=1012, gid=100, mode=0100644, size=0) > Clearing orphaned inode 26470857 (uid=1012, gid=100, mode=0100644, size=0) > Clearing orphaned inode 26470840 (uid=1012, gid=100, mode=0100644, size=0) > Pass 1: Checking inodes, blocks, and sizes > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > Pass 4: Checking reference counts > Pass 5: Checking group summary information > > > This is after building a bintuils packages on lustre clients and then checking > the filesystem. > > Any idea how critical it is?
This is normal even for local ext3 filesystems, if they crash with open but unlinked files. If the filesystem has been stopped normally (not forced) then this shouldn't be happening. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. _______________________________________________ Lustre-discuss mailing list [email protected] https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
