You can subscribe to this list here.
2009 |
Jan
|
Feb
(31) |
Mar
(70) |
Apr
(35) |
May
(32) |
Jun
(18) |
Jul
(65) |
Aug
(79) |
Sep
(26) |
Oct
(19) |
Nov
(37) |
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(28) |
Feb
(24) |
Mar
(22) |
Apr
(34) |
May
(18) |
Jun
(17) |
Jul
|
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
2011 |
Jan
(7) |
Feb
(11) |
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
(9) |
Sep
(4) |
Oct
|
Nov
(8) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Aleksey T. <ale...@gm...> - 2015-08-28 09:55:56
|
On 08/27/2015 07:54 PM, Павел Сафронов wrote: Pavel, > Hi. There is an issue with remotefs and inode numbers. > By default fuse assigns sequential number to inode and when you're using > mv on file its inode changes. It is very bad behaviour for mounting logs > for further processing of them. > I concur with the patch, it is applied to master. In sequential commit i've bumped remotefs version and marked it incompatible with previous versions (see README.protocol). "use_ino" option is added to allowed for mount.rfs. Good catch on "port" option, also added to allowed. Thank you. |
From: Павел С. <pv....@gm...> - 2015-08-27 16:54:40
|
Hi. There is an issue with remotefs and inode numbers. By default fuse assigns sequential number to inode and when you're using mv on file its inode changes. It is very bad behaviour for mounting logs for further processing of them. Here is the example (between 2 calls of stat there is mv 1 2 on server where rfsd was started and inode of the same file has been changed by fuse) root@dev1f nginx # stat 1 File: `1' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 27h/39d Inode: 13 Links: 1 Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-08-27 16:33:06.000000000 +0300 Modify: 2015-08-27 16:33:06.000000000 +0300 Change: 2015-08-27 16:33:06.000000000 +0300 Birth: - root@dev1f nginx # stat 2 File: `2' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 27h/39d Inode: 16 Links: 1 Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-08-27 16:33:06.000000000 +0300 Modify: 2015-08-27 16:33:06.000000000 +0300 Change: 2015-08-27 16:33:24.000000000 +0300 Birth: - So it is a good idea to get inode number from underlying filesystem. Here is the patch implementing this feature http://pastebin.com/622YQBqz Not really sure that I've done it right but at least it works. To get this work one need to use fuse mount option use_ino (it also requires mount.rfs changes to allow pass this options to rfs from /etc/fstab, I've added "port=*|use_ino" to mount.rfs script (port option is missing from this script too)). |
From: Aleksey T. <ale...@gm...> - 2015-08-27 13:18:15
|
-------- Forwarded Message -------- Subject: Re: [remotefs-devel] Problem with resolving host to multiple addresses Date: Thu, 27 Aug 2015 06:17:53 +0300 From: Aleksey Tulinov <ale...@gm...> To: Павел Сафронов <pv....@gm...> On 08/26/2015 10:20 PM, Павел Сафронов wrote: Pavel, > I'm facing a problem with connection to host that have both ipv6 and > ipv4 addresses. > The problem is in file src/connect.c in function rfs_connect() > This function iterates over all addresses of host. So when the first > address is accessible and the second is not everything fails, because it > sets sock variable to -1 and overwrites already connected socket. > > The fix for this problem is in patch (it exits from the while loop when > rfs successfully connects to remote host). > Thank you for looking into this, your patch is applied. In sequential commit i tried to reduce number of branches, i just like it more that way. It shouldn't break your changes, please let me know if it works for you. > PS And the main question: is anybody still supports remotefs and can > push fix to upstream? > It is still supported, patches and suggestions are very welcome. |
From: Павел С. <pv....@gm...> - 2015-08-26 19:21:04
|
Hey, everybody. I'm facing a problem with connection to host that have both ipv6 and ipv4 addresses. The problem is in file src/connect.c in function rfs_connect() This function iterates over all addresses of host. So when the first address is accessible and the second is not everything fails, because it sets sock variable to -1 and overwrites already connected socket. The fix for this problem is in patch (it exits from the while loop when rfs successfully connects to remote host). --- src/connect.c 2015-08-26 21:46:46.792658932 +0300 +++ src/connect.c 2015-08-26 21:51:13.741661955 +0300 @@ -153,6 +153,10 @@ close(sock); sock = -1; } + else + { + break; + } resolved_item = resolved_item->next; } PS And the main question: is anybody still supports remotefs and can push fix to upstream? |
From: Alexey B. <ba...@ir...> - 2012-09-13 13:33:57
|
On Thu, 13 Sep 2012 11:37:10 +0400 Alexey Bazhin <ba...@ir...> wrote: > > This kind of problem (connectivity) was addressed in current trunk > > (future 0.16), is it possible to `svn co > > svn://svn.code.sf.net/p/remotefs/code/trunk remotefs-code && cd > > remotefs-code && make rfsdeb` and try if 0.16 has this issue? > I'll try it Yes, it works now without hangs, thanx. -- Alexey Bazhin <ba...@ir...> |
From: Alexey B. <ba...@ir...> - 2012-09-13 07:37:30
|
On Mon, 10 Sep 2012 21:25:15 +0300 Aleksey Tulinov <ale...@gm...> wrote: > On Mon, Sep 10, 2012 at 6:59 PM, Alexey Bazhin <ba...@ir...> wrote: > > Hello, > > > After upgrading client to Ubuntu Quantal (fuse-2.9.0-1ubuntu2) I'm > > expiriencing occasional hangs on remotefs. Backtrace is following: > > That's odd. What are the symptoms of this on the remote end? Did you > lose connectivity, or any troubles with the connection? No troubles with connection. > This kind of problem (connectivity) was addressed in current trunk > (future 0.16), is it possible to `svn co > svn://svn.code.sf.net/p/remotefs/code/trunk remotefs-code && cd > remotefs-code && make rfsdeb` and try if 0.16 has this issue? I'll try it -- Alexey Bazhin <ba...@ir...> |
From: Aleksey T. <ale...@gm...> - 2012-09-10 18:25:21
|
On Mon, Sep 10, 2012 at 6:59 PM, Alexey Bazhin <ba...@ir...> wrote: Hello, > After upgrading client to Ubuntu Quantal (fuse-2.9.0-1ubuntu2) I'm > expiriencing occasional hangs on remotefs. Backtrace is following: That's odd. What are the symptoms of this on the remote end? Did you lose connectivity, or any troubles with the connection? This kind of problem (connectivity) was addressed in current trunk (future 0.16), is it possible to `svn co svn://svn.code.sf.net/p/remotefs/code/trunk remotefs-code && cd remotefs-code && make rfsdeb` and try if 0.16 has this issue? |
From: Alexey B. <ba...@ir...> - 2012-09-10 16:19:03
|
Hi! After upgrading client to Ubuntu Quantal (fuse-2.9.0-1ubuntu2) I'm expiriencing occasional hangs on remotefs. Backtrace is following: (gdb) bt #0 0x00007fe3d7f70703 in select () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fe3d846f6ec in rfs_recv () from /usr/lib/librfs.so.0.15 #2 0x00007fe3d846a962 in ?? () from /usr/lib/librfs.so.0.15 #3 0x00007fe3d8467e41 in rfs_read () from /usr/lib/librfs.so.0.15 #4 0x00007fe3d8682eff in fuse_fs_read_buf () #from /lib/x86_64-linux-gnu/libfuse.so.2 5 0x00007fe3d868309d in ?? () #from /lib/x86_64-linux-gnu/libfuse.so.2 6 0x00007fe3d868a02e in ?? () #from /lib/x86_64-linux-gnu/libfuse.so.2 7 0x00007fe3d868a947 in ?? () #from /lib/x86_64-linux-gnu/libfuse.so.2 8 0x00007fe3d86871af in #fuse_session_loop () from /lib/x86_64-linux-gnu/libfuse.so.2 9 #0x00007fe3d867f1d8 in fuse_loop () #from /lib/x86_64-linux-gnu/libfuse.so.2 10 0x00007fe3d868f2ff in ?? () #from /lib/x86_64-linux-gnu/libfuse.so.2 11 0x0000000000401994 in ?? () #12 0x00007fe3d7ea676d in __libc_start_main () #from /lib/x86_64-linux-gnu/libc.so.6 13 0x0000000000401ae5 in ?? () 14 #0x00007fffeb683e18 in ?? () 15 0x000000000000001c in ?? () #16 0x0000000000000005 in ?? () #17 0x00007fffeb685e28 in ?? () #18 0x00007fffeb685e2c in ?? () #19 0x00007fffeb685e4a in ?? () #20 0x00007fffeb685e5b in ?? () #21 0x00007fffeb685e5e in ?? () #22 0x0000000000000000 in ?? () Sending any signal (STOP and CONT for example) interrupts select() and rfs starts working again until it hangs next time. -- Alexey Bazhin <ba...@ir...> |
From: <ale...@us...> - 2012-07-28 19:52:17
|
Revision: 1297 http://remotefs.svn.sourceforge.net/remotefs/?rev=1297&view=rev Author: aleksey_t Date: 2012-07-28 19:52:11 +0000 (Sat, 28 Jul 2012) Log Message: ----------- +updated depends +updated tests Modified Paths: -------------- trunk/build/Makefiles/depends.mk unit/base.mk unit/build/depends.mk Added Paths: ----------- unit/tests/sockets.cpp This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2012-07-28 17:17:27
|
Revision: 1296 http://remotefs.svn.sourceforge.net/remotefs/?rev=1296&view=rev Author: aleksey_t Date: 2012-07-28 17:17:20 +0000 (Sat, 28 Jul 2012) Log Message: ----------- +more simplification Modified Paths: -------------- trunk/src/id_lookup.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2012-07-28 17:04:22
|
Revision: 1295 http://remotefs.svn.sourceforge.net/remotefs/?rev=1295&view=rev Author: aleksey_t Date: 2012-07-28 17:04:16 +0000 (Sat, 28 Jul 2012) Log Message: ----------- +simplification Modified Paths: -------------- trunk/src/id_lookup.c trunk/src/id_lookup.h trunk/src/nss/handlers/getnames.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2012-07-28 16:49:07
|
Revision: 1294 http://remotefs.svn.sourceforge.net/remotefs/?rev=1294&view=rev Author: aleksey_t Date: 2012-07-28 16:49:00 +0000 (Sat, 28 Jul 2012) Log Message: ----------- +read/write/connect timeouts Modified Paths: -------------- trunk/src/config.h trunk/src/connect.c trunk/src/operations/rfs/reconnect.c trunk/src/sendrecv.c trunk/src/sockets.c trunk/src/sockets.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2012-06-12 20:51:58
|
Revision: 1293 http://remotefs.svn.sourceforge.net/remotefs/?rev=1293&view=rev Author: aleksey_t Date: 2012-06-12 20:51:52 +0000 (Tue, 12 Jun 2012) Log Message: ----------- +applied patch for Darwin build Modified Paths: -------------- trunk/src/inet.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2012-04-15 00:25:20
|
Revision: 1292 http://remotefs.svn.sourceforge.net/remotefs/?rev=1292&view=rev Author: aleksey_t Date: 2012-04-15 00:25:14 +0000 (Sun, 15 Apr 2012) Log Message: ----------- +fixed locking Modified Paths: -------------- trunk/src/operations/lock.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2012-04-15 00:24:48
|
Revision: 1291 http://remotefs.svn.sourceforge.net/remotefs/?rev=1291&view=rev Author: aleksey_t Date: 2012-04-15 00:24:42 +0000 (Sun, 15 Apr 2012) Log Message: ----------- +minor fixes +cleaup Modified Paths: -------------- trunk/build/Makefiles/base.mk trunk/src/list_exports.c trunk/src/operations/rfs/reconnect.c trunk/src/operations.h trunk/src/rfs.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: Aleksey T. <ale...@gm...> - 2012-03-12 21:00:45
|
On Mon, Mar 12, 2012 at 10:25 PM, Markus Grabner <gr...@ic...> wrote: > It's use case 1. If user A logs into the system and wants to access data of > user B, which user B decided to make readable (but not writeable) by everyone > (e.g., permissions 0644), then user A can perform his tasks even if the server > accesses the data with permissions of user A. However, if user A logs off, and > user B logs in before the automount expires, then user B will not be able to > modify his data since the server still tries to access B's data with the > permissions of A. The same problem occurs with multiple users accessing > concurrently, of course. Is this possible with remotefs? > Through different mount points - yes. 1. localhost:/home/A/shared,username=A -> 10.0.0.1:/var/shared,ugo 2. localhost:/home/B/shared,username=B -> 10.0.0.1:/var/shared,ugo /var/shared on 10.0.0.1 might have files owned by both A and B. If you use UGO for this export, then A can access 644 files of B in r/o, but not in r/w, B can access his files normally using his own connection. You can also access files concurrently with different permissions if you use 2 connections. You need to put both connections to auto-mount, of course. Not possible using a single mount point though, but this is how remotefs is designed and i'm pretty much like it this way. Management of permissions on single connection will require major changes in design that introduces security risks and et cetera. P.S. Concurrency is not a strong point of remotefs, it's recommended to use multiple connection for concurrent access when possible, even you use the same user/permissions on server. On the other hand, multiple connections are supposed to be cheap in remotefs. |
From: Aleksey T. <ale...@gm...> - 2012-03-12 18:57:51
|
On Mon, Mar 12, 2012 at 1:24 AM, Markus Grabner <gr...@ic...> wrote: Hello Markus, > *) Did I miss some configuration option which makes such a multiuser setup > possible in combination with automount? > It's not clear to me what is your use-case: 1) Do you need single mount point (on client) and multiple users concurrently accessing it with their access rights, or 2) Is it enough to have multiple mount points with own access rights each? (which excludes concurrent access) If 2) then it's doable with ugo, usual auto-mount for each user and uid= option in fstab. For user "alice" it would be mount to /home/alice/remote with username=alice on remote, for user "bob" it would be /home/bob/remote with username=bob. Is that it? > *) If it is not currently supported by remotefs, how difficult would it be to > add such a feature? > |
From: Markus G. <gr...@ic...> - 2012-03-11 23:41:52
|
Hi! Since NFS performs poorly over my home WLAN, I was looking for a 1:1 replacement and came across remotefs, and after a few tests I think it can solve the performance issues - great work! There is one issue with permissions and the way the server gets mounted, though. With NFS, it is easy to use automount to mount a filesystem, and users can access the data according to their permissions. When mounting a remotefs filesystem via automount, it gets mounted with the username option specified in the automount configuration, i.e., the server doesn't know the actual id of the user (on the client side) who is requesting data. I don't think that the ugo and acl options can solve this since the server always accesses its local file system with the same user id, regardless of the client user initiating a request. So my questions are: *) Did I miss some configuration option which makes such a multiuser setup possible in combination with automount? *) If it is not currently supported by remotefs, how difficult would it be to add such a feature? Thanks & kind regards, Markus -- Markus Grabner Institute for Computer Graphics and Vision Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria WWW: http://www.icg.tugraz.at/Members/grabner |
From: Ricky C. <rch...@mu...> - 2011-11-15 01:11:17
|
Ricky-Charlets-MacBook-Pro:remotefs-0.15-2 rickycharlet$ diff src/inet.h.orig src/inet.h 43c43 < # include <machine/endian.h> --- > # include <libkern/OSByteOrder.h> -- Live strong, Ricky Charlet |
From: <ale...@us...> - 2011-11-13 18:30:52
|
Revision: 1290 http://remotefs.svn.sourceforge.net/remotefs/?rev=1290&view=rev Author: aleksey_t Date: 2011-11-13 18:30:46 +0000 (Sun, 13 Nov 2011) Log Message: ----------- +updated unittest for exports to cover latest fix Modified Paths: -------------- unit/tests/exports.cpp This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2011-11-13 18:30:22
|
Revision: 1289 http://remotefs.svn.sourceforge.net/remotefs/?rev=1289&view=rev Author: aleksey_t Date: 2011-11-13 18:30:15 +0000 (Sun, 13 Nov 2011) Log Message: ----------- +fixed exports parsing (no NL at the EOF) Modified Paths: -------------- trunk/src/exports.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2011-11-06 21:38:24
|
Revision: 1288 http://remotefs.svn.sourceforge.net/remotefs/?rev=1288&view=rev Author: aleksey_t Date: 2011-11-06 21:38:18 +0000 (Sun, 06 Nov 2011) Log Message: ----------- +fixed handshake +changed incompatibility flag to EPROTONOSUPPORT Modified Paths: -------------- trunk/src/handlers/rfs/handshake.c trunk/src/operations/rfs/handshake.c trunk/src/operations/rfs/reconnect.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2011-11-06 20:49:51
|
Revision: 1287 http://remotefs.svn.sourceforge.net/remotefs/?rev=1287&view=rev Author: aleksey_t Date: 2011-11-06 20:49:45 +0000 (Sun, 06 Nov 2011) Log Message: ----------- +updated test Modified Paths: -------------- unit/tests/attr_cache.cpp unit/tests/sendrecv.cpp This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2011-11-06 20:12:32
|
Revision: 1286 http://remotefs.svn.sourceforge.net/remotefs/?rev=1286&view=rev Author: aleksey_t Date: 2011-11-06 20:12:25 +0000 (Sun, 06 Nov 2011) Log Message: ----------- +fixed warning in readdir Modified Paths: -------------- trunk/src/handlers/readdir.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ale...@us...> - 2011-11-06 20:08:58
|
Revision: 1285 http://remotefs.svn.sourceforge.net/remotefs/?rev=1285&view=rev Author: aleksey_t Date: 2011-11-06 20:08:52 +0000 (Sun, 06 Nov 2011) Log Message: ----------- +64-bit statfs +attr cache ttl increased +introduced README.protocol +version bump Modified Paths: -------------- trunk/build/Makefiles/version.mk trunk/src/changelog.c trunk/src/config.h trunk/src/handlers/statfs.c trunk/src/operations/statfs.c Added Paths: ----------- trunk/README.protocol This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |