From: <get...@gm...> - 2006-10-17 16:39:40
|
Hello, I'm implementing a virtual filesystem that has real filesystem as backend. And so, all I'm doing is redirecting every fuse operation to it's corresponding system call, so using direct_io I can map read and write directly to the read and write system calls. It's directly based on the fusexmp.c example. The problem is that I want to execute scripts in that filesystem but when I try to execute something I get a :Bad Address error. I have read in the mailing list that it was a problem between nmap() and direct_io and that I had to remove a couple of lines from the kernel/file.c file but in the 2.6.0-rc3 version there aren't that lines anymore. So the question is: Using FUSE 2.6.0 can I use direct_io and execute scripts in my filesystem at the same time? --=20 Regards. Jos=E9 Antonio S=E1nchez |
From: Miklos S. <mi...@sz...> - 2006-10-17 18:38:36
|
> Hello, I'm implementing a virtual filesystem that has real filesystem > as backend. And so, all I'm doing is redirecting every fuse operation > to it's corresponding system call, so using direct_io I can map read > and write directly to the read and write system calls. It's directly > based on the fusexmp.c example. > The problem is that I want to execute scripts in that filesystem but > when I try to execute something I get a :Bad Address error. I have > read in the mailing list that it was a problem between nmap() and > direct_io and that I had to remove a couple of lines from the > kernel/file.c file but in the 2.6.0-rc3 version there aren't that > lines anymore. Yes 2.6 is slightly different. Try copying this line from 'fuse_file_operations' structure: .mmap = fuse_file_mmap, into the 'fuse_direct_io_file_operations' structure. It might work. No guarantees ;) Miklos |
From: <get...@gm...> - 2006-10-18 09:30:33
|
Thanks for the quick answer but it didn't work. I changed the fuse_direct_io_file_operations structure, and then I recompiled everything, even the kernel module. Anyway, when using direct_io and trying to execute a script I still get the :Bad Address error. Anyway, I want to execute unmodified scripts in my filesystem. That scripts are going to read and write to files, so, without using direct_io, How can I map the read and write system call so I can return exactly what this scripts expect? I have read that if you return less than it's requested, the remaining space is filled with zeros. Does it affect to a program that request a read? Should the program expect to find zeros when it gets data less than it requested? On 10/17/06, Miklos Szeredi <mi...@sz...> wrote: > > Hello, I'm implementing a virtual filesystem that has real filesystem > > as backend. And so, all I'm doing is redirecting every fuse operation > > to it's corresponding system call, so using direct_io I can map read > > and write directly to the read and write system calls. It's directly > > based on the fusexmp.c example. > > The problem is that I want to execute scripts in that filesystem but > > when I try to execute something I get a :Bad Address error. I have > > read in the mailing list that it was a problem between nmap() and > > direct_io and that I had to remove a couple of lines from the > > kernel/file.c file but in the 2.6.0-rc3 version there aren't that > > lines anymore. > > Yes 2.6 is slightly different. > > Try copying this line from 'fuse_file_operations' structure: > > .mmap =3D fuse_file_mmap, > > into the 'fuse_direct_io_file_operations' structure. > > It might work. No guarantees ;) > > Miklos > > > --=20 Saludos. Jos=E9 Antonio S=E1nchez |
From: Miklos S. <mi...@sz...> - 2006-10-18 09:53:25
|
> Thanks for the quick answer but it didn't work. I changed the > fuse_direct_io_file_operations structure, and then I recompiled > everything, even the kernel module. Did you verify that you are using the new kernel module? I.e. did you unload the old module and load the new module? > Anyway, when using direct_io and trying to execute a script I still > get the :Bad Address error. Anyway, I want to execute unmodified > scripts in my filesystem. That scripts are going to read and write > to files, so, without using direct_io, How can I map the read and > write system call so I can return exactly what this scripts expect? You have two choices: 1) determine the file size before it is opened 2) use direct_io If you don't know the file size in advance, even mmap() can't work as expected, that is why mmap is disallowed in combination with direct_io. Miklos |
From: <get...@gm...> - 2006-10-18 10:05:20
|
On 10/18/06, Miklos Szeredi <mi...@sz...> wrote: > > Thanks for the quick answer but it didn't work. I changed the > > fuse_direct_io_file_operations structure, and then I recompiled > > everything, even the kernel module. > > Did you verify that you are using the new kernel module? I.e. did you > unload the old module and load the new module? Yes, I even rebooted. Anyway, is there a way to know if I'm using the new module or the standard kernel module? > > Anyway, when using direct_io and trying to execute a script I still > > get the :Bad Address error. Anyway, I want to execute unmodified > > scripts in my filesystem. That scripts are going to read and write > > to files, so, without using direct_io, How can I map the read and > > write system call so I can return exactly what this scripts expect? > > You have two choices: > > 1) determine the file size before it is opened > 2) use direct_io > > If you don't know the file size in advance, even mmap() can't work as > expected, that is why mmap is disallowed in combination with direct_io. I can get the file size before something is read or written but it's not guaranteed that size may not change if another process is accessing the file. All I want to do is a filesystem that catches operations over the real filesystem (just like the fusexmp.c example) to do some logging in the middle. So that filesystem must work as a normal filesystem would work. That's why I need direct_io and that's why I need to execute scripts (a normal filesystem must allow execution of scripts over it). > Miklos > --=20 Saludos. Jos=E9 Antonio S=E1nchez |
From: Miklos S. <mi...@sz...> - 2006-10-18 10:27:25
|
> > > Thanks for the quick answer but it didn't work. I changed the > > > fuse_direct_io_file_operations structure, and then I recompiled > > > everything, even the kernel module. > > > > Did you verify that you are using the new kernel module? I.e. did you > > unload the old module and load the new module? > > Yes, I even rebooted. Anyway, is there a way to know if I'm using the > new module or the standard kernel module? Put some identifier into the printk in fuse_init(). > > > Anyway, when using direct_io and trying to execute a script I still > > > get the :Bad Address error. Anyway, I want to execute unmodified > > > scripts in my filesystem. That scripts are going to read and write > > > to files, so, without using direct_io, How can I map the read and > > > write system call so I can return exactly what this scripts expect? > > > > You have two choices: > > > > 1) determine the file size before it is opened > > 2) use direct_io > > > > If you don't know the file size in advance, even mmap() can't work as > > expected, that is why mmap is disallowed in combination with direct_io. > > I can get the file size before something is read or written but it's > not guaranteed that size may not change if another process is > accessing the file. > > All I want to do is a filesystem that catches operations over the real > filesystem (just like the fusexmp.c example) to do some logging in the > middle. So that filesystem must work as a normal filesystem would > work. That's why I need direct_io and that's why I need to execute > scripts (a normal filesystem must allow execution of scripts over it). I don't see why you'd need direct_io for that? If all filesystem accesses go through the fuse filesystem, then everything will be perfectly consistent. Otherwise there might be inconsistencies, but they aren't usually problematic. Miklos |
From: <get...@gm...> - 2006-10-18 14:23:41
|
I have inserted a printk and now I'm sure I'm using the modified module. So changing fuse_direct_io_file_operations doesn't help. On 10/18/06, Miklos Szeredi <mi...@sz...> wrote: > > The problem is with the read and write operations. If an application > > requests X bytes but in fuse I call to read and I obtain X-Y bytes, > > That's not exactly right, it will return X-Z bytes depending on the > size of the file (obtained through ->getattr()). > > You are right that this it could handle the short read better and > change the file size, instead of padding the result with zero bytes. > I should fix that in a future release. > > But this is an unlikely situation, where the file size changed between > the getattr() call and the read(). > > > then the application will receive X bytes instead of X-Y and some of > > them will be zero. That's not what the application expects. It expects > > that the fuse read and write operation will behave exactly as the read > > and write system calls. In the fuse.h file it says that to behave like > > the system calls, direct_io must be enabled. > > This is usually only relevant if the size of the file cannot be known > for some reason, or if caching the file data must never be done. > > Miklos > I don't know if I get it right. When an application request a read over a fuse filesystem it first checks the file size to see if all the data can be delivered. The problem here is if some other process changes the file size before the getattr is invoked and after the read call invocation, so fuse thinks that all the data can be delivered but this is not right anymore. Am I wrong? --=20 Saludos. Jos=E9 Antonio S=E1nchez |