From: <ma...@ne...> - 2011-11-23 01:59:36
|
Hello It seems there is no way for a FUSE filesystem to get the client process secondary groups, at least through the FUSE protocol. It is always possible to get the information from /proc, but this is at the expense of opening a file there for each filesystem operation. Are there plans on how to address that? It would probably require an upgrade to the FUSE protocol, either by modifying struct fuse_in_header, or by adding a trailer to packets with that information attached. Anyone thought about it? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Sven U. <sve...@gm...> - 2011-11-25 19:34:11
|
Hello Emmanuel, > It seems there is no way for a FUSE filesystem to get the client process > secondary groups, at least through the FUSE protocol. It is always > possible to get the information from /proc, but this is at the expense > of opening a file there for each filesystem operation. > > Are there plans on how to address that? It would probably require an > upgrade to the FUSE protocol, either by modifying struct fuse_in_header, > or by adding a trailer to packets with that information attached. Anyone > thought about it? I would very much like to see a nice solution to that too. Sven -- _ ___ ___ ___ The dCache File System __| |/ __|| __|/ __| An archive file-system for PB of data / _` | (__ | _| \__ \ http://www.desy.de/~utcke/Data/ \__,_|\___||_| |___/ http://www.dr-utcke.de/ |
From: <ma...@ne...> - 2011-11-26 02:46:34
|
Sven Utcke <sve...@gm...> wrote: > > Are there plans on how to address that? It would probably require an > > upgrade to the FUSE protocol, either by modifying struct fuse_in_header, > > or by adding a trailer to packets with that information attached. Anyone > > thought about it? > I would very much like to see a nice solution to that too. I could prepare a patch for that and add support to NetBSD for using it. Of course someone would have to do the work for the Linux kernel. The simplier approach seems to add a field in struct fuse_in_header: uint32_t groups[NGROUPS_MAX]; Of course we need to check version number and use the older header for older filesystems in order to maintain backward compatibility. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Jean-Pierre A. <jea...@wa...> - 2011-11-26 15:57:13
|
Hi, > Message du 23/11/11 03:00 > De : "Emmanuel Dreyfus" > A : fus...@li... > Copie à : > Objet : [fuse-devel] Secondary groups > > Hello > > It seems there is no way for a FUSE filesystem to get the client process > secondary groups, at least through the FUSE protocol. It is always > possible to get the information from /proc, but this is at the expense > of opening a file there for each filesystem operation. > > Are there plans on how to address that? It would probably require an > upgrade to the FUSE protocol, either by modifying struct fuse_in_header, Does the current fuse_getgroups() not suit your needs ? It may be unimplemented on some OS, but the protocol is at least defined. Actually, this will not avoid getting data from /proc, as this is what fuse_getgroups() does on Linux, but it will avoid code duplication unless you want to stay compatible with older fuse versions. see http://fuse.sourcearchive.com/documentation/2.8.1/fuse_8h_04273db088e57d8242caa388193b6958.html Regards Jean-Pierre |
From: <ma...@ne...> - 2011-11-27 02:05:59
|
Jean-Pierre ANDRE <jea...@wa...> wrote: > Does the current fuse_getgroups() not suit your needs ? It may be > unimplemented on some OS, but the protocol is at least defined. > > Actually, this will not avoid getting data from /proc, as this is what > fuse_getgroups() does on Linux, but it will avoid code duplication > unless you want to stay compatible with older fuse versions. The idea would be to avoid reading /proc (or calling sysctl on NetBSD) to retreive secondary groups, for the sake of performances. When it crafts the FUSE packet, the kernel has the secondary groups at hands, it would be more efficient if it could attach them to the FUSE packet, instead of having the filesystem retreive them later. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Miklos S. <mi...@sz...> - 2011-12-05 12:44:25
|
On Sun, Nov 27, 2011 at 3:18 AM, Emmanuel Dreyfus <ma...@ne...> wrote: > Jean-Pierre ANDRE <jea...@wa...> wrote: > >> Does the current fuse_getgroups() not suit your needs ? It may be >> unimplemented on some OS, but the protocol is at least defined. >> >> Actually, this will not avoid getting data from /proc, as this is what >> fuse_getgroups() does on Linux, but it will avoid code duplication >> unless you want to stay compatible with older fuse versions. > > The idea would be to avoid reading /proc (or calling sysctl on NetBSD) > to retreive secondary groups, for the sake of performances. When it > crafts the FUSE packet, the kernel has the secondary groups at hands, it > would be more efficient if it could attach them to the FUSE packet, > instead of having the filesystem retreive them later. Patches are welcome. But please take into account that in most cases the filesystem isn't interested in the secondary groups and so care is needed not to introduce a performance regression in the majority for the sake of a performance improvement in the minority. Thanks, Miklos |
From: Emmanuel D. <ma...@ne...> - 2011-12-05 13:30:24
|
On Mon, Dec 05, 2011 at 01:44:17PM +0100, Miklos Szeredi wrote: > But please take into account that in most cases the filesystem isn't > interested in the secondary groups and so care is needed not to > introduce a performance regression in the majority for the sake of a > performance improvement in the minority. It could be enabled by a FUSE_XHEADER flag in the init message. If the kernel returns the flag in the reply, then this means subsequent messages will start by struct fuse_in_xheader instead of struct fuse_in_header. Here there is a choice to make: I can just add secondary groups to struct fuse_in_xheader, or I can make an extensible struct fuse_in_xheader where secondary groups or other information can be added. In that later case, another init flag (FUSE_SECONDARY_GROUPS) would cause secondary groups to be appended. Here is a proposal for the extensible header. Note that without option, it remains binary compatible with the original one. Also note that header_len will make sure that future changes can be handled gracefully by the filesystem: it will just have to skip the extra data. struct fuse_in_xheader { __u32 len; __u32 opcode; __u64 unique; __u64 nodeid; __u32 uid; __u32 gid; __u32 pid; __u8 version: /* header version for later changes */ __u8 padding; __u16 header_len; /* header length including options */ /* More optionnal data, starting by struct fuse_in_xheader_option */ }; Each option would start by struct fuse_in_xhopt, which would give the option type and length. If the filesystem does not care about one, it can skip: struct fuse_in_xhopt { __u16 type; /* FUSE_XHOPT_* */ __u16 option_len; } And here is the structure for secondary groups: #define FUSE_XHOPT_GROUPS 1 struct fuse_in_xhopt_groups { __u16 type; /* FUSE_XHOPT_GROUPS */ __u16 option_len; /* sizeof(struct fuse_in_xhopt_groups) */ __u32 ngroups; __u32 groups[NGROUPS]; } OTOH, if this is considered overkill, I can just do an unextensible new header, with just groups added: struct fuse_in_xheader { __u32 len; __u32 opcode; __u64 unique; __u64 nodeid; __u32 uid; __u32 gid; __u32 pid; __u32 ngroups; __u32 groups[NGROUPS]; }; -- Emmanuel Dreyfus ma...@ne... |
From: Miklos S. <mi...@sz...> - 2011-12-06 14:58:51
|
On Mon, Dec 5, 2011 at 2:30 PM, Emmanuel Dreyfus <ma...@ne...> wrote: > It could be enabled by a FUSE_XHEADER flag in the init message. > If the kernel returns the flag in the reply, then this means subsequent > messages will start by struct fuse_in_xheader instead of > struct fuse_in_header. > > Here there is a choice to make: I can just add secondary groups to > struct fuse_in_xheader, or I can make an extensible struct fuse_in_xheader > where secondary groups or other information can be added. In that later > case, another init flag (FUSE_SECONDARY_GROUPS) would cause secondary > groups to be appended. I think I prefer a combination of the two: - add header_len to end of fuse_in_header - omit the version, we already have a protocol version, no need to separately version the headers - add a fuse_in_groups header but without the type and length fields - add an init flag to negotiate the use of the groups header Thanks, Miklos |
From: <ma...@ne...> - 2011-12-07 01:33:46
|
Miklos Szeredi <mi...@sz...> wrote: > - add header_len to end of fuse_in_header > - omit the version, we already have a protocol version, no need to > separately version the headers > - add a fuse_in_groups header but without the type and length fields > - add an init flag to negotiate the use of the groups header Ok, but that means that if we ever want to add another class of data in the header, the secondary groups will also have to be included between the original header and the new data. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: Miklos S. <mi...@sz...> - 2011-12-07 14:33:58
|
ma...@ne... (Emmanuel Dreyfus) writes: > Miklos Szeredi <mi...@sz...> wrote: > >> - add header_len to end of fuse_in_header >> - omit the version, we already have a protocol version, no need to >> separately version the headers >> - add a fuse_in_groups header but without the type and length fields >> - add an init flag to negotiate the use of the groups header > > Ok, but that means that if we ever want to add another class of data in > the header, the secondary groups will also have to be included between > the original header and the new data. Not necessarily. Optional headers can be controlled by flags in the INIT message. I think it makes little sense to have a message-by-message control of optional headers. The "header_len" field is just there for robustness, the length of the optional headers should always be calculable. Thanks, Miklos |