Should a Filesystem's Global Data be Mutex Locked?

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

Should a Filesystem's Global Data be Mutex Locked?

Tony Kaku
Excuse me,

I'm developing a very simple filesystem that mirrors the root directory,
replacing every space character of every filename with a dot, so that
programs ported from the Plan 9 operating system can manipulate them.

The fs works by storing filtered and unfiltered filenames in a linked
list of the form:

typedef struct Name Name;
struct Name {
        char old[NAME_MAX+1];
        char new[NAME_MAX+1];
        Name *next;
};

I'd like to know if I have to implement any mutex locking for the linked
list? I know fuse is multithreaded, but does it assure only one fs
operation is executing at a time or is that the fs developer's job?

Also, is use of file handles in fuse_file_info freeform? That is, can I
assign a fh to a file the first time the file system sees that file, and
then add it to the file's corresponding Name struct to speed up searching?

Thanks,
tonykaku

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should a Filesystem's Global Data be Mutex Locked?

Michael Theall-2
Hi Tony,

If you are using libfuse's multithreaded mode, you are responsible for your own locking. You can certainly have multiple request callbacks happening at the same time. There are some operations which are serialized, but to avoid depending on any specific behavior, you should assume any callback can happen from any thread at any time for any file/directory.

The 'fh' member of fuse_file_info is an opaque value that is stored with the open file/directory kernel struct. When open file/directory calls (like read/write/fstat/close/readdir) happen, FUSE can pass that value to your callbacks. Typically you would put some index or pointer to your server's open file/directory context so you can use it in those callbacks. For example, 'fi->fh = new OpenFile(path, flags);' in the open callback, 'OpenFile *fh = reinterpret_cast<OpenFile*>(fi->fh); fh->read(buffer, size);' in the subsequent read callback, 'OpenFile *fh = reinterpret_cast<OpenFile*>(fi->fh); delete fh;' in the release callback.

You can assign anything you want to 'fi->fh' in the open/opendir calls (it's a 64-bit value); that value will be available to your callbacks. It's only limited by your creativity. It sounds like you want to put a pointer to Name in 'fi->fh'. I think you probably instead need to have another struct that contains a pointer to Name (along with other information related to the open file context), and assign that type of struct to 'fi->fh'.

Regards,
Michael Theall

On Fri, Jan 27, 2017 at 1:46 PM Tony Kaku <[hidden email]> wrote:
Excuse me,

I'm developing a very simple filesystem that mirrors the root directory,
replacing every space character of every filename with a dot, so that
programs ported from the Plan 9 operating system can manipulate them.

The fs works by storing filtered and unfiltered filenames in a linked
list of the form:

typedef struct Name Name;
struct Name {
        char old[NAME_MAX+1];
        char new[NAME_MAX+1];
        Name *next;
};

I'd like to know if I have to implement any mutex locking for the linked
list? I know fuse is multithreaded, but does it assure only one fs
operation is executing at a time or is that the fs developer's job?

Also, is use of file handles in fuse_file_info freeform? That is, can I
assign a fh to a file the first time the file system sees that file, and
then add it to the file's corresponding Name struct to speed up searching?

Thanks,
tonykaku

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel