On Fri, 2008-01-25 at 14:56 +0000, Ben Yarwood wrote: > I will try and find more information on the errors in the logs but I think the problem was that I was using a 32bit system and tried > to expand over 16TB. I didn't realize this was the size limit until I read the FAQ afterwards. Is this the root cause of the > problem? > > I now have the file system mounted again and am copying what I can off it by moving the files by name. So far we have copied over > 250GB of files and not a single file has failed to copy or caused the file system to withdraw. It is fortunate that we knew the > name of every file on the file system. Not really understanding the structure of the file system myself, do you think it's possible > we will recover all the files using this method? > > > Thanks > Ben Hi Ben, Yes, using a 32-bit system to expand beyond 16TB might cause that problem. I added some smarts to gfs_fsck in late 2006 so that it won't let you run a gfs_fsck from a 32-bit system if your file system is > 16TB. Perhaps gfs_grow needs more smarts regarding the file system size as well. That seems like an easy fix that's well worth making. I suspect you can get most (or all) of your data back by copying it off like you're doing. That's because even if the new RG information is corrupt, you will likely not have tried to allocate any new data into that RG, so the copy will hopefully not encounter the corruption. That's just a guess, not knowing what those RGs really look like. Regards, Bob Peterson Red Hat GFS -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
