Re: gfs_fsck fails on large filesystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Robert Peterson wrote:

We've tried to kick around ideas on how to improve the speed, such as
(1) adding an option to only focus on areas where the journals are dirty,
(2) introducing multiple threads to process the different RGs, and even
(3) trying to get multiple nodes in the cluster to team up and do different
areas of the file system.  None of these have been implemented yet
because of higher priorities. Since this is an open-source project, anyone
could step in and do these.  Volunteers?


I've tried to look at the code many times. But, as a clustered file system is a complex thing, it gets hard to figure out what it's all about. I tried to find a "big picture" documentation, at least for on-disk layout. The only nearest thing i've found is : http://opengfs.sourceforge.net/docs.php , which is the documentation written at the time OpenGFS forked from Cistina's code. Although principles may still be the sames (or not ?), the code has obviously changed and on-disk layout may not be the same, too. So, is there some sort of documentation about the principles found in OpenGFS (not a design doc, i've read /usr/src/linux/Documentation/stable_api_nonsense.txt) ? This would much help anybody who wishes to enter the code to do it more efficientely...

--
Mathieu

--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster

[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux