Re: [Linux-cluster] Re: [PATCH 00/14] GFS
On Aug 10, 2005, at 09:26:26, AJ Lewis wrote: On Wed, Aug 10, 2005 at 12:11:10PM +0100, Christoph Hellwig wrote: On Wed, Aug 10, 2005 at 01:09:17PM +0200, Lars Marowsky-Bree wrote: So for every directory hierarchy on a shared filesystem, each user needs to have the complete list of bindmounts needed, and automatically resync that across all nodes when a new one is added or removed? And then have that executed by root, because a regular user can't? Do it in an initscripts and let users simply not do it, they shouldn't even know what kind of filesystem they are on. I'm just thinking of a 100-node cluster that has different mounts on different nodes, and trying to update the bind mounts in a sane and efficient manner without clobbering the various mount setups. Ouch. How about something like the following: cpslink() => Create a Context Dependent Symlink readcpslink() => Return the Context Dependent path data readlink() => Return the path of the Context Dependent Symlink as it would be evaluated in the current context, basically as a normal symlink. lstat()=> Return information on the Context Dependent Symlink in the same format as a regular symlink. unlink() => Delete the Context Dependent Symlink. You would need an extra userspace tool that understands cpslink/ readcpslink to create and get information on the links for now, but ls and ln could eventually be updated, and until then the would provide sane behavior. Perhaps this should be extended into a new API for some of the strange things several filesystems want to do in the VFS: extlink() => Create an extended filesystem link (with type specified) readextlink() => Return the path (and type) for the link The filesystem could define how each type of link acts with respect to other syscalls. OpenAFS could use extlink() instead of their symlink magic for adjusting the AFS volume hierarchy. The new in-kernel AFS client could use it in similar fashion (It has no method to adjust hierarchy, because it's still read-only). GFS could use it for their Context Dependent Symlinks. Since it would pass the type in as well, it would be possible to use it for different kinds of links on the same filesystem. Cheers, Kyle Moffett -- Simple things should be simple and complex things should be possible -- Alan Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: [PATCH 00/14] GFS
On Wed, Aug 10, 2005 at 12:11:10PM +0100, Christoph Hellwig wrote: > On Wed, Aug 10, 2005 at 01:09:17PM +0200, Lars Marowsky-Bree wrote: > > So for every directoy hiearchy on a shared filesystem, each user needs > > to have the complete list of bindmounts needed, and automatically resync > > that across all nodes when a new one is added or removed? And then have > > that executed by root, because a regular user can't? > > Do it in an initscripts and let users simply not do it, they shouldn't > even know what kind of filesystem they are on. I'm just thinking of a 100-node cluster that has different mounts on different nodes, and trying to update the bind mounts in a sane and efficient manner without clobbering the various mount setups. Ouch. -- AJ Lewis Voice: 612-638-0500 Red HatE-Mail: [EMAIL PROTECTED] One Main Street SE, Suite 209 Minneapolis, MN 55414 Current GPG fingerprint = D9F8 EDCE 4242 855F A03D 9B63 F50C 54A8 578C 8715 Grab the key at: http://people.redhat.com/alewis/gpg.html or one of the many keyservers out there... pgpsGmjTnZdeF.pgp Description: PGP signature
Re: [Linux-cluster] Re: [PATCH 00/14] GFS
On Wed, Aug 10, 2005 at 12:11:10PM +0100, Christoph Hellwig wrote: On Wed, Aug 10, 2005 at 01:09:17PM +0200, Lars Marowsky-Bree wrote: So for every directoy hiearchy on a shared filesystem, each user needs to have the complete list of bindmounts needed, and automatically resync that across all nodes when a new one is added or removed? And then have that executed by root, because a regular user can't? Do it in an initscripts and let users simply not do it, they shouldn't even know what kind of filesystem they are on. I'm just thinking of a 100-node cluster that has different mounts on different nodes, and trying to update the bind mounts in a sane and efficient manner without clobbering the various mount setups. Ouch. -- AJ Lewis Voice: 612-638-0500 Red HatE-Mail: [EMAIL PROTECTED] One Main Street SE, Suite 209 Minneapolis, MN 55414 Current GPG fingerprint = D9F8 EDCE 4242 855F A03D 9B63 F50C 54A8 578C 8715 Grab the key at: http://people.redhat.com/alewis/gpg.html or one of the many keyservers out there... pgpsGmjTnZdeF.pgp Description: PGP signature
Re: [Linux-cluster] Re: [PATCH 00/14] GFS
On Aug 10, 2005, at 09:26:26, AJ Lewis wrote: On Wed, Aug 10, 2005 at 12:11:10PM +0100, Christoph Hellwig wrote: On Wed, Aug 10, 2005 at 01:09:17PM +0200, Lars Marowsky-Bree wrote: So for every directory hierarchy on a shared filesystem, each user needs to have the complete list of bindmounts needed, and automatically resync that across all nodes when a new one is added or removed? And then have that executed by root, because a regular user can't? Do it in an initscripts and let users simply not do it, they shouldn't even know what kind of filesystem they are on. I'm just thinking of a 100-node cluster that has different mounts on different nodes, and trying to update the bind mounts in a sane and efficient manner without clobbering the various mount setups. Ouch. How about something like the following: cpslink() = Create a Context Dependent Symlink readcpslink() = Return the Context Dependent path data readlink() = Return the path of the Context Dependent Symlink as it would be evaluated in the current context, basically as a normal symlink. lstat()= Return information on the Context Dependent Symlink in the same format as a regular symlink. unlink() = Delete the Context Dependent Symlink. You would need an extra userspace tool that understands cpslink/ readcpslink to create and get information on the links for now, but ls and ln could eventually be updated, and until then the would provide sane behavior. Perhaps this should be extended into a new API for some of the strange things several filesystems want to do in the VFS: extlink() = Create an extended filesystem link (with type specified) readextlink() = Return the path (and type) for the link The filesystem could define how each type of link acts with respect to other syscalls. OpenAFS could use extlink() instead of their symlink magic for adjusting the AFS volume hierarchy. The new in-kernel AFS client could use it in similar fashion (It has no method to adjust hierarchy, because it's still read-only). GFS could use it for their Context Dependent Symlinks. Since it would pass the type in as well, it would be possible to use it for different kinds of links on the same filesystem. Cheers, Kyle Moffett -- Simple things should be simple and complex things should be possible -- Alan Kay - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: [PATCH 00/14] GFS
Mike Christie wrote: > David Teigland wrote: > >>On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote: >> >> >>>* Why are you using bufferheads extensively in a new filesystem? >> >> >>bh's are used for metadata, the log, and journaled data which need to be >>written at the block granularity, not page. >> > > > In a scsi tree > http://kernel.org/git/?p=linux/kernel/git/jejb/scsi-block-2.6.git;a=summary oh yeah it is in -mm too. > there is a function, bio_map_kern(), in fs.c that maps a buffer into a > bio. It does not have to be page granularity. Can something like that be > used in these places? > > -- > Linux-cluster mailing list > [EMAIL PROTECTED] > http://www.redhat.com/mailman/listinfo/linux-cluster - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: [PATCH 00/14] GFS
David Teigland wrote: > On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote: > >>* Why are you using bufferheads extensively in a new filesystem? > > > bh's are used for metadata, the log, and journaled data which need to be > written at the block granularity, not page. > In a scsi tree http://kernel.org/git/?p=linux/kernel/git/jejb/scsi-block-2.6.git;a=summary there is a function, bio_map_kern(), in fs.c that maps a buffer into a bio. It does not have to be page granularity. Can something like that be used in these places? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: [PATCH 00/14] GFS
David Teigland wrote: On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote: * Why are you using bufferheads extensively in a new filesystem? bh's are used for metadata, the log, and journaled data which need to be written at the block granularity, not page. In a scsi tree http://kernel.org/git/?p=linux/kernel/git/jejb/scsi-block-2.6.git;a=summary there is a function, bio_map_kern(), in fs.c that maps a buffer into a bio. It does not have to be page granularity. Can something like that be used in these places? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: [PATCH 00/14] GFS
Mike Christie wrote: David Teigland wrote: On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote: * Why are you using bufferheads extensively in a new filesystem? bh's are used for metadata, the log, and journaled data which need to be written at the block granularity, not page. In a scsi tree http://kernel.org/git/?p=linux/kernel/git/jejb/scsi-block-2.6.git;a=summary oh yeah it is in -mm too. there is a function, bio_map_kern(), in fs.c that maps a buffer into a bio. It does not have to be page granularity. Can something like that be used in these places? -- Linux-cluster mailing list [EMAIL PROTECTED] http://www.redhat.com/mailman/listinfo/linux-cluster - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
