Iozone problem

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Iozone problem

Leandro Franco
Hi...

I read someone mentioned Iozone in one of the emails and i decided to
give it a try, unfortunately it doesnt want to work on my pc...

(btw... i think it's related with
http://sourceforge.net/mailarchive/message.php?msg_id=11872325 but i
didnt see any conclusion there.. so sorry if it has been reviewed
already)

if i do something like:

tmp]$ iozone -Ra -g 1G

it will start doing its bussiness and at the beginning we will get
something like

open("iozone.tmp", O_WRONLY|O_CREAT|O_LARGEFILE, 0) = 3
ftruncate(3, 0)                         = 0
close(3)                                = 0
unlink("iozone.tmp")                    = 0
open("iozone.tmp", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0640) = 3
close(3)                                = 0
open("iozone.tmp", O_RDWR|O_LARGEFILE)  = 3
fsync(3)                                = 0

tmp]$ ls -lh
total 72K
-rw-r-----    1 franco   franco        64K Aug 16 15:31 iozone.tmp


but when i tried the same in a fusexmp_fh directory i get:
open("iozone.tmp", O_WRONLY|O_CREAT|O_LARGEFILE, 0) = -1 EACCES
(Permission denied)
write(1, "\nCan not open temp file: iozone."..., 36
Can not open temp file: iozone.tmp
) = 36


and from fusexmp:
LOOKUP /tmp/iozone/iozone.tmp
   unique: 1603, error: -2 (No such file or directory), outsize: 16
unique: 1604, opcode: MKNOD (8), nodeid: 134, insize: 59
MKNOD /tmp/iozone/iozone.tmp
   NODEID: 137
   unique: 1604, error: 0 (Success), outsize: 136
unique: 1605, opcode: OPEN (14), nodeid: 137, insize: 48
   unique: 1605, error: -13 (Permission denied), outsize: 16

after that we see that the file was created but there are no rights so
we wont be able to open it:
iozone]$ ls -lh
total 0
----------    1 franco   franco          0 Aug 16 15:38 iozone.tmp


is mknod creating the file with the wrong mode or is there something
in the functionality that i'm missing?


Thank you
Leandro


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Iozone problem

Miklos Szeredi
> but when i tried the same in a fusexmp_fh directory i get:
> open("iozone.tmp", O_WRONLY|O_CREAT|O_LARGEFILE, 0) = -1 EACCES
> (Permission denied)
> write(1, "\nCan not open temp file: iozone."..., 36
> Can not open temp file: iozone.tmp
> ) = 36
>
>
> and from fusexmp:
> LOOKUP /tmp/iozone/iozone.tmp
>    unique: 1603, error: -2 (No such file or directory), outsize: 16
> unique: 1604, opcode: MKNOD (8), nodeid: 134, insize: 59
> MKNOD /tmp/iozone/iozone.tmp
>    NODEID: 137
>    unique: 1604, error: 0 (Success), outsize: 136
> unique: 1605, opcode: OPEN (14), nodeid: 137, insize: 48
>    unique: 1605, error: -13 (Permission denied), outsize: 16
>
> after that we see that the file was created but there are no rights so
> we wont be able to open it:
> iozone]$ ls -lh
> total 0
> ----------    1 franco   franco          0 Aug 16 15:38 iozone.tmp
>
>
> is mknod creating the file with the wrong mode or is there something
> in the functionality that i'm missing?


Look at the strace output carefully: the first time the file mode is
0, the second time it's 0640.

Fusexmp_fh fails on the first open, because it first creates the file
(which no permissions) and then tries to open it, which won't succeed.

Now this is a tricky situation.  The root of the problem is how linux
handles the open() system call: it splits it into several filesystem
methods, create, check-permission, truncate, and open, depending on
the flags.

In this case it was first a create, then the open.  Note that in this
case the kernel doesn't check the permission after create: it knows it
has just created the file and open should not fail.

But fusexmp_fh doesn't work this way, since it does check the
permissions on open.

So what's the solution?

1) Work around this in filesystems by doing the open without
permission checking.  For example fusexmp_fh, could do this:

static int xmp_open(const char *path, struct fuse_file_info *fi)
{
    int fd;

    fd = open(path, fi->flags);
    if(fd == -1) {
        if (errno == EACCES) {
            struct stat stbuf;
            int needmode;
           
            switch (fi->flags & O_ACCMODE) {
            case O_RDONLYL:
                needmode = 0400;
                break;

            case O_WRONLY:
                needmode = 0200;
                break;
               
            default:
                needmode = 0600;
            }
           
            /* try changing permissions */
            if (stat(path, &stbuf) != -1 &&
                chmod(path, stbuf.st_mode | needmode) != -1)  {
                fd = open(path, fi->flags);
                chmod(path, stbuf.st_mode);
                if (fd == -1)
                    return -errno;
            } else
                return -EACCES;
        } else
            return -errno;
    }

    fi->fh = fd;
    return 0;
}

It's ugly, racy, but would work most of the time.

But now there's another problem.  Permission won't be checked even if
the file wasn't newly created.  This is bad, the user can now open for
writing a file which write permission is disabled.

This isn't solvable with 2.3.0 and older FUSE.  2.4 will have an
access() method that (if defined) will be called before open (if
needed).


2) Make an atomic create/open method.  With current linux kernels this
   is not possible (well, that's not strictly true, but it would have
   several problems).

   Trond Myklebust has a patch pending, which should allow such a
   method to be cleanly implemented, so hopefully in a not so distant
   future, there will be a kernel under which this open problem can
   properly be solved.

Hope this clears the issue up a bit.

Miklos


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Iozone problem

Valient Gough
On Tuesday 16 August 2005 16:46, Miklos Szeredi wrote:
> But now there's another problem.  Permission won't be checked even if
> the file wasn't newly created.  This is bad, the user can now open for
> writing a file which write permission is disabled.
>
> This isn't solvable with 2.3.0 and older FUSE.  2.4 will have an
> access() method that (if defined) will be called before open (if
> needed).

But if the fuse option "default_permissions" is set, then aren't the
permissions checked in the kernel before a call to open?

I use a workaround similar to what you described, but my filesystem defaults
to setting default_permissions flag, and I'm not able to edit a file which is
marked read-only..

regards,
Valient


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Iozone problem

Miklos Szeredi
> > But now there's another problem.  Permission won't be checked even if
> > the file wasn't newly created.  This is bad, the user can now open for
> > writing a file which write permission is disabled.
> >
> > This isn't solvable with 2.3.0 and older FUSE.  2.4 will have an
> > access() method that (if defined) will be called before open (if
> > needed).
>
> But if the fuse option "default_permissions" is set, then aren't the
> permissions checked in the kernel before a call to open?

Yes, with the 'default_permissions' mount option, this is not a
problem.

But with some filesystems 'default_permissions' is not a solution,
because the permissions simply cannot be calculated from the owner,
group and mode.  An example is sshfs, where the uid/gid on the remote
server has no meaning on the client.

> I use a workaround similar to what you described, but my filesystem
> defaults to setting default_permissions flag, and I'm not able to
> edit a file which is marked read-only..

It's how it should work :)

Miklos


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel