|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
|
|
Contradicting create() behaviourHi,
I'm currently implementing a network-based file system using FUSE, and I must say that you guys have done a great job! It took me no time at all to get up and running, and now, two days later, my file system <-> FUSE plug-in is almost done. One big issue remains: When i use 'touch' to create a file, I see that FUSE issues a getattr() call, gets a -ENOENT from me, and the proceeds to create the file and verify it's there using an other getattr(). So far so good. When I issue a cp command to copy a file into the FS, I see FUSE run three getattr() calls in a row, and then proceed to run create(), which is immediately followed by release(), presumably because the previous calls to getattr() failed, even though they were called BEFORE create(), so they should have. Obviously, my cp command fails because of that. For example (tmp is the directory mounted using FUSE): $ cp /home/gilad/Manager tmp/newfile13 unique: 2511, opcode: LOOKUP (1), nodeid: 1, insize: 50 LOOKUP /newfile13 getattr: /newfile13 getattr: file not found, return -2 unique: 2511, error: -2 (No such file or directory), outsize: 16 unique: 2512, opcode: LOOKUP (1), nodeid: 1, insize: 50 LOOKUP /newfile13 getattr: /newfile13 getattr: file not found, return -2 unique: 2512, error: -2 (No such file or directory), outsize: 16 unique: 2513, opcode: LOOKUP (1), nodeid: 1, insize: 50 LOOKUP /newfile13 getattr: /newfile13 getattr: file not found, return -2 unique: 2513, error: -2 (No such file or directory), outsize: 16 unique: 2514, opcode: CREATE (35), nodeid: 1, insize: 58 NODEID: 3 release: closing file /newfile13 delete: 3 unique: 2514, error: -5 (Input/output error), outsize: 16 -- END EXAMPLE -- Again, using 'touch' seems to call the functions in the right order, When I try the cp command again, after the file was created, it succeeds. any reason for such contradicting behavior? What am I missing? Using Ubuntu 8.04, stock fuse kernel module and lib. Thanks, Gilad ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourGilad Rom <gilad@...> writes:
> When I issue a cp command to copy a file into the FS, I see > FUSE run three getattr() calls in a row, and then proceed to run > create(), which is immediately followed by release(), presumably because > the previous calls to getattr() failed, even though they were called > BEFORE create(), so they should have. Obviously, my cp command fails > because of that. create() creates *and* opens a file. After cp has written the contents, it closes the file, which correctly results in release() being called. There is no connection between the getattr() and the release() call. I guess your fs assumes that create() creates a file without opening it. Hope that helps, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourOn Wed, 2008-07-16 at 15:21 +0200, Nikolaus Rath wrote:
> Gilad Rom <gilad@...> writes: > > When I issue a cp command to copy a file into the FS, I see > > FUSE run three getattr() calls in a row, and then proceed to run > > create(), which is immediately followed by release(), presumably because > > the previous calls to getattr() failed, even though they were called > > BEFORE create(), so they should have. Obviously, my cp command fails > > because of that. > > create() creates *and* opens a file. After cp has written the > contents, it closes the file, which correctly results in release() > being called. There is no connection between the getattr() and the > release() call. > > I guess your fs assumes that create() creates a file without opening > it. > Actually, it does just that. The network file system has no 'create', so I use open for both open() and create(). Gilad > > Hope that helps, > > -Nikolaus > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourGilad Rom <gilad@...> writes:
> On Wed, 2008-07-16 at 15:21 +0200, Nikolaus Rath wrote: >> Gilad Rom <gilad@...> writes: >> > When I issue a cp command to copy a file into the FS, I see >> > FUSE run three getattr() calls in a row, and then proceed to run >> > create(), which is immediately followed by release(), presumably because >> > the previous calls to getattr() failed, even though they were called >> > BEFORE create(), so they should have. Obviously, my cp command fails >> > because of that. >> >> create() creates *and* opens a file. After cp has written the >> contents, it closes the file, which correctly results in release() >> being called. There is no connection between the getattr() and the >> release() call. >> >> I guess your fs assumes that create() creates a file without opening >> it. > > Actually, it does just that. The network file system has no > 'create', so I use open for both open() and create(). In that case I don't quite understand your description above: >>> the previous calls to getattr() failed, even though they were called >>> BEFORE create(), so they should have. What should have (done?) what? >>> Obviously, my cp command fails because of that. Because of what, exactly? To me the error message looks as if either the release() or some subsequent call returns an error. Could you check which function is called last before the "unique: 2514, error: -5 (Input/output error), outsize: 16" line appears and what value it returns? Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourOn Wed, 2008-07-16 at 16:08 +0200, Nikolaus Rath wrote:
> Gilad Rom <gilad@...> writes: > > On Wed, 2008-07-16 at 15:21 +0200, Nikolaus Rath wrote: > >> Gilad Rom <gilad@...> writes: > >> > When I issue a cp command to copy a file into the FS, I see > >> > FUSE run three getattr() calls in a row, and then proceed to run > >> > create(), which is immediately followed by release(), presumably because > >> > the previous calls to getattr() failed, even though they were called > >> > BEFORE create(), so they should have. Obviously, my cp command fails > >> > because of that. > >> > >> create() creates *and* opens a file. After cp has written the > >> contents, it closes the file, which correctly results in release() > >> being called. There is no connection between the getattr() and the > >> release() call. > >> > >> I guess your fs assumes that create() creates a file without opening > >> it. > > > > Actually, it does just that. The network file system has no > > 'create', so I use open for both open() and create(). > > In that case I don't quite understand your description above: > >>> the previous calls to getattr() failed, even though they were called > >>> BEFORE create(), so they should have. > > What should have (done?) what? > What I mean is that the getattr() calls all return -ENOENT, as they should, since the file is not there and has not been created yet. > >>> Obviously, my cp command fails because of that. > > Because of what, exactly? > 1. fuse calls getattr() 3 times in a row 2. fuse calls create() 3. fuse SHOULD call getattr() again, but calls delete 4. cp fails #3 is what I don't understand. The create() function in #2 works normally, and returns 0. Why is delete() called right after? What I _think_ is happening is that create(), for some reason, is called AFTER the getattr() call which should have been there to verify the new file's existence, so getattr() returns an error, because create() has not been called yet. Is that better? ;) Why is getattr() called 3 times in a row instead of once, and why is it not called after create() ? again, the behavior I see when I touch a file is: 1. fuse calls getattr() once 2. fuse calls create() 3. fuse calls getattr() once more Which is perfectly fine. Thanks, Gilad ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourGilad Rom <gilad@...> writes:
>> >>> Obviously, my cp command fails because of that. >> >> Because of what, exactly? >> > > 1. fuse calls getattr() 3 times in a row > 2. fuse calls create() > 3. fuse SHOULD call getattr() again, but calls delete > 4. cp fails > > #3 is what I don't understand. The create() function in #2 works > normally, and returns 0. Why is delete() called right after? Do you actually have a function called delete() that is called by fuse? If so, what does it do? According to the CVS fuse.h, there is no such function. > What I _think_ is happening is that create(), for some reason, is > called AFTER the getattr() call which should have been there to > verify the new file's existence, so getattr() returns an error, > because create() has not been called yet. Is that better? ;) Yes, but I think you're wrong. After all, you're not getting ENOENT but EIO. Could you please check the return code of the last function that is called by fuse? (Either release() or the delete function that is unknown to me) > Why is getattr() called 3 times in a row instead of once, This is most likely because some calls are generated by cp itself. Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourThere are a long list of FUSE-based file systems that work, and none of them
have a problem with cp. It would seem pretty straightforward to test one of these file system to see what should be happening during a cp. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourOn Wed, 2008-07-16 at 19:24 +0200, Nikolaus Rath wrote:
> Gilad Rom <gilad@...> writes: > >> >>> Obviously, my cp command fails because of that. > >> > >> Because of what, exactly? > >> > > > > 1. fuse calls getattr() 3 times in a row > > 2. fuse calls create() > > 3. fuse SHOULD call getattr() again, but calls delete > > 4. cp fails > > > > #3 is what I don't understand. The create() function in #2 works > > normally, and returns 0. Why is delete() called right after? > > Do you actually have a function called delete() that is called by > fuse? If so, what does it do? According to the CVS fuse.h, there is no > such function. > No, the function's name is release(). Sorry for the confusion. > > What I _think_ is happening is that create(), for some reason, is > > called AFTER the getattr() call which should have been there to > > verify the new file's existence, so getattr() returns an error, > > because create() has not been called yet. Is that better? ;) > > Yes, but I think you're wrong. After all, you're not getting ENOENT > but EIO. Could you please check the return code of the last function > that is called by fuse? (Either release() or the delete function that > is unknown to me) > Yeah, that's the problem right there. I dont have a single line of code that returns -EIO. They all either return 0 or -ENOENT. read() returns the number of bytes read, but that's not a problem, since it is never called in this context. and create() returns -EACCES if it fails, which is not the case, since it succeeds every time. (I'm left with a zero byte file after the command fails. If I run it again, everything works) I've verified that both create() and release() return 0 using gdb breakpoints. > > > Why is getattr() called 3 times in a row instead of once, > > This is most likely because some calls are generated by cp itself. > True, using "echo hi > somefile" looks better, but still fails. > > Best, > > -Nikolaus > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourOn Wed, 2008-07-16 at 13:34 -0400, Allen Pulsifer wrote:
> There are a long list of FUSE-based file systems that work, and none of them > have a problem with cp. It would seem pretty straightforward to test one of > these file system to see what should be happening during a cp. > This problem is not cp specific, but happens every single time I try to write to a file that does not exist (thus creating it in the process), whereas simply creating a file using touch works fine. The funny thing is that the exact same functions are called both times and return the same values... Gilad > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > fuse-devel mailing list > fuse-devel@... > https://lists.sourceforge.net/lists/listinfo/fuse-devel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourGilad Rom <gilad@...> writes:
>> > What I _think_ is happening is that create(), for some reason, is >> > called AFTER the getattr() call which should have been there to >> > verify the new file's existence, so getattr() returns an error, >> > because create() has not been called yet. Is that better? ;) >> >> Yes, but I think you're wrong. After all, you're not getting ENOENT >> but EIO. Could you please check the return code of the last function >> that is called by fuse? (Either release() or the delete function that >> is unknown to me) >> > > Yeah, that's the problem right there. I dont have a single line > of code that returns -EIO. They all either return 0 or -ENOENT. > read() returns the number of bytes read, but that's not a problem, > since it is never called in this context. > > and create() returns -EACCES if it fails, which is not the case, > since it succeeds every time. (I'm left with a zero byte file > after the command fails. If I run it again, everything works) > > I've verified that both create() and release() return 0 using gdb > breakpoints. As Allen already said, this is still most likely a bug in your implementation. What happens if you don't define a create function at all, and let fuse call mknod and open instead? Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviour> This problem is not cp specific, but happens every single
> time I try to write to a file that does not exist (thus > creating it in the process), whereas simply creating a file > using touch works fine. It might not be cp specific, but it is definitely specific to your file system. If you had tried comparing your file system to one that works, you would probably have this fixed already. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
|
|
|
Re: Contradicting create() behaviourOn Wed, 2008-07-16 at 20:33 +0200, Nikolaus Rath wrote:
> What happens if you don't define a create function at all, and let > fuse call mknod and open instead? > Now everything works as expected... I simply pasted the code from my create() function (and added some code to close the file right after creating it, since open() is called next), and fuse is happy and reports no errors. Is this the "right" way to do things, or should I still try to implement create()? is there a down side to using mknod+open instead? I'm not worried about file creation times, as this file system will be mostly used for massive parallel read/writes without many new files added at a time. Thanks! Gilad > Best, > > -Nikolaus > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourHello,
,---- | On Wed, 2008-07-16 at 20:33 +0200, Nikolaus Rath wrote: | > What happens if you don't define a create function at all, and let | > fuse call mknod and open instead? | > | | Now everything works as expected... I simply pasted the code from my | create() function (and added some code to close the file right after | creating it, since open() is called next), and fuse is happy and reports | no errors. So what happens if you define a create function that *only* calls mknod() and open()? | | Is this the "right" way to do things, or should I still try to implement | create()? is there a down side to using mknod+open instead? That's an alternative way to do things, but using create() should work just as well. Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourOn Thu, 17 Jul 2008, Nikolaus Rath wrote:
> | > | Is this the "right" way to do things, or should I still try to implement > | create()? is there a down side to using mknod+open instead? > > That's an alternative way to do things, but using create() should work > just as well. Right. The EIO is caused by ->getattr() not returning a correct st_mode value, i.e. S_ISREG(buf.st_mode) fails. (Yeah, I know, should be better ducumented ;) Miklos ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviourMiklos Szeredi <miklos@...> writes:
> On Thu, 17 Jul 2008, Nikolaus Rath wrote: >> | >> | Is this the "right" way to do things, or should I still try to implement >> | create()? is there a down side to using mknod+open instead? >> >> That's an alternative way to do things, but using create() should work >> just as well. > > Right. > > The EIO is caused by ->getattr() not returning a correct st_mode > value, i.e. S_ISREG(buf.st_mode) fails. > > (Yeah, I know, should be better ducumented ;) If can explain it to me, I may provide another patch :-). From what function is EIO returned if S_ISREG fails? I didn't quite get it... Best, -Nikolaus -- »It is not worth an intelligent man's time to be in the majority. By definition, there are already enough people to do that.« -J.H. Hardy PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
|
|
Re: Contradicting create() behaviour |