Date: Thu, 02 Dec 2004 23:32:54 +0530 From: "Kamal R. Prasad" <kamalp@acm.org> To: Andre Oppermann <andre@freebsd.org> Cc: "current@freebsd.org" <current@freebsd.org> Subject: Re: My project wish-list for the next 12 months Message-ID: <41AF58CE.10904@acm.org> In-Reply-To: <41AF53E1.80408@freebsd.org> References: <41AE3F80.1000506@freebsd.org> <41AF29AC.6030401@freebsd.org> <Pine.LNX.4.60.0412021225170.27619@athena> <41AF53E1.80408@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andre Oppermann wrote: > Sam wrote: > >> On Thu, 2 Dec 2004, Andre Oppermann wrote: >> >>> Scott Long wrote: >>> >>>> 5. Clustered FS support. SANs are all the rage these days, and >>>> clustered filesystems that allow data to be distributed across many >>>> storage enpoints and accessed concurrently through the SAN are very >>>> powerful. RedHat recently bought Sistina and re-opened the GFS source >>>> code, so exploring this would be very interesting. >>> >>> >>> There are certain steps that can be be taken one at a time. For >>> example >>> it should be relatively easy to mount snapshots (ro) from more than one >>> machine. Next step would be to mount a full 'rw' filesystem as 'ro' on >>> other boxes. This would require cache and sector invalidation >>> broadcasting >>> from the 'rw' box to the 'ro' mounts. The holy grail of course is >>> to mount >>> the same filesystem 'rw' on more than one box, preferrably more than >>> two. >>> This requires some more involved synchronization and locking on top >>> of the >>> cache invalidation. And make sure that the multi-'rw' cluster stays >>> alive >>> if one of the participants freezes and doesn't respond anymore. >>> >>> Scrolling through the UFS/FFS code I think the first one is 2-3 days of >>> work. The second 2-4 weeks and the third 2-3 month to get it right. >>> If someone would throw up the money... >> >> >> You might also design in consideration for data redundancy. Right now >> GFS largely relies on the SAN box to export already redundant RAID >> disks. GFS sits on a "cluster aware" lvm layer that is supposed to >> be able to do mirroring and striping, but I'm told it's not >> stable enough for "production" use. > > > Data redundancy would require a UFS/FFS redesign. I'm 'only' talking > about enhancing UFS/FFS but keeping anything ondisk the same (plus > some more elements). > If you add redundancy code into UFS/FFS, that will slow down its performance (even for those not seeking redundancy). A better way would be to have another filesystem implementation like VxFS (veritas filesystem). Im not sure if they have published papers/put their techniques into public domain. regards -kamal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41AF58CE.10904>