First we write the code, then we do the design.
Well, generally it is a better idea to do things in the other order, but

in the case of SMP locking I had a general idea what needed doing and

wanted to see how some of the code looked before finishing the design

note.  Then the trial patch made such a big stability improvement I did

another one... then another one... until coverage was complete as far

as I could see.  So now I can write about what was done, and we can

think about what holes I left, if any.
Locking design is a slippery subject.  There is no way to prove the

absence of race conditions, only their presence.  We have to think

about every bit of data that Tux3 owns in kernel and make sure all of

it is either unshared, read only or covered by some lock whenever it is

accessed.
So we start by enumerating everything a Tux3 filesystem has in memory:
  - Superblock fields
  - Inode table btree in buffer cache
  - Cached inodes with attributes

      - Extended attribute cache (xcache)
  - File index btrees in buffer cache
  - Data blocks of special files in page cache:

      - Allocation bitmap

      - Directories

      - Atom table
That is it.  Pretty simple, really.  We will add a few more animals to

this menagerie over time, for example a hash to accelerate xattr atom

lookup and some bookkeeping for atomic merge, but the main structures

have already arrived.
Now we go through each and ask "what, if anything, already serializes

access to this object?"  If the answer is "nothing" or "not always"

then we need to add serialization.  The following are taken care of for

us:
  VFS superblock:
     - Everything in it is read-only or protected by the VFS

       with lock_super() (sb->s_lock mutex)
     - VFS superblock points to the Tux3 superblock, which contains

       fields not protected by the VFS superblock locking
  Directories:
      - Directory entry blocks are taken care of for us by VFS taking

        ->i_mutex of t...
[ message continues ]

To set an extended attribute:
  echo <text> | tux3 set <filename> <attrname>
To get an extended attribute:
  tux3 get <filename> <attrname>
Enjoy,
Daniel
_______________________________________________

Tux3 mailing list

Tux3@tux3.org

http://tux3.org/cgi-bin/mailman/listinfo/tux3

Hi,
this patch adds a preliminary support of extended attributes

to tux3fuse.c. This is very lightly tested:
$ ls

$ date > testfile.txt

$ cat testfile.txt

Thu Sep 11 14:48:00 EEST 2008

$ getfattr -n hello testfile.txt

testfile.txt: hello: No such attribute

$ setfattr -n hello -v world testfile.txt

$ getfattr -n hello testfile.txt

# file: testfile.txt

hello="world"
$ setfattr -n foo -v bar testfile.txt

$ getfattr -n hello testfile.txt

# file: testfile.txt

hello="world"
$ getfattr -n foo testfile.txt

# file: testfile.txt

foo="bar"
---
diff -r ab052a0cd40c user/test/tux3fuse.c

--- a/user/test/tux3fuse.c	Thu Sep 11 02:55:03 2008 -0700

+++ b/user/test/tux3fuse.c	Thu Sep 11 14:47:08 2008 +0300

@@ -40,6 +40,7 @@

 #include <errno.h>

 #include <fcntl.h>

 #include <inttypes.h>

+#include <attr/xattr.h>

 #include <sys/types.h>

 #include "trace.h"

 #include "tux3.h"

@@ -344,9 +345,13 @@

 		goto nomem;

 	if (!(sb->rootdir = new_inode(sb, 0xd)))

 		goto nomem;

+	if (!(sb->atable = new_inode(sb, 0xa)))

+		goto eek;

 	if ((errno = -open_inode(sb->bitmap)))

 		goto eek;

 	if ((errno = -open_inode(sb->rootdir)))

+		goto eek;

+	if ((errno = -open_inode(sb->atable)))

 		goto eek;

 	return;

 nomem:

@@ -369,7 +374,37 @@

 static void tux3_setattr(fuse_req_t req, fuse_ino_t ino, struct stat *attr,

 	int to_set, struct fuse_file_info *fi)

 {

-	fuse_reply_err(req, ENOSYS);

+	struct inode *inode = ino2inode(ino);

+

+	if (to_set & FUSE_SET_ATTR_MODE) {

+		printf("Setting mode\n");

+	}

+	if (to_set & FUSE_SET_ATTR_UID) {

+		printf("Setting uid\n");

+	}

+	if (to_set & FUSE_SET_ATTR_GID) {

+		printf("Setting gid\n");

+	}

+	if (to_set & FUSE_SET_ATTR_SIZE) {

+		printf("Setting size\n");

+	}

+	if (to_set & FUSE_SET_ATTR_ATIME) {

+		printf("Setting atime to %Lu\n", (L)attr->st_atime);

+		inode->i_atime = attr->st_atime;

+		// !! no persistent atime support yet

+	}

+	if (to_set & ...
[ message continues ]

Very nicely done!   I did not find the file /usr/include/attr/xattr.h

and I did find /usr/include/sys/xattr.h, so I barged in and changed the

include, and also changed ENOATTR to ENOENT to make it compile, then I

checked it in.
Of course this was wrong, as I knew I would find out by asking you.  I

noticed your test script uses setfattr and getfatter, which I do not

have on my system, but apt-cache search told me they are available in a

package called attr.  Good, I installed it, and it brought in the

libattr1 package.  But still no /usr/include/attr/xattr.h header!  But

installing libattr1-dev got me the header.
So it seems we have a new build dependency: libattr1-dev.  And we have

a way of compiling without it, the only bad effect of which is to return

ENOENT instead of ENOATTR, which does not seem like such a bad thing

considering you return EEXIST in your fuse patch, which wrongly implies

that the offending object is a file, just as ENOENT does.
Of course we can handle this nicely with pkg-config, right?  Well,
   pkg-config --cflags libattr1

   Package libattr1 was not found in the pkg-config search path.

   Perhaps you should add the directory containing `libattr1.pc'

   to the PKG_CONFIG_PATH environment variable

   No package 'libattr1' found 
Bummer.  Upstream for this package... or is it the package maintainer...

does not know or care about pkg-config.  Also, upstream for sys headers

does know know or care about xattrs, or my headers are out of date

which is a distinct possibility.
Anybody have suggestions on how to tidy this up, including where to send

patches upstream?
Until we have at least a pkg-config type solution I think we are better

off returning a slightly wrong error code than adding another build

dependency, thus steepening the pain curve for new Tux3 members

compiling for the first time.  I could be wrong about that, maybe we are

nowhere close to the pain threshold for dependencies yet.
Regards,
Daniel
__________________________________...
[ message continues ]

Well, the man-page of setxattr has this information:
	If XATTR_CREATE is specified, and the attribute exists already,

	errno is set to EEXIST.  If XATTR_REPLACE is specified, and the

	attribute does not exist, errno is set to ENOATTR.
and attr/xattr.h has this:
#ifndef ENOATTR

# define ENOATTR ENODATA        /* No such attribute */

#endif
_______________________________________________

Tux3 mailing list

Tux3@tux3.org

http://tux3.org/cgi-bin/mailman/listinfo/tux3

man setxattr: If extended attributes are not supported by the

filesystem, or are disabled, errno is set to ENOTSUP.
_______________________________________________

Tux3 mailing list

Tux3@tux3.org

http://tux3.org/cgi-bin/mailman/listinfo/tux3

Any reason we should ever disable them?  I can't think of any

reason to make xattr support optional, particularly with the plan

being to use largely the same mechanism as regular file data.
Regards,
Daniel
_______________________________________________

Tux3 mailing list

Tux3@tux3.org

http://tux3.org/cgi-bin/mailman/listinfo/tux3

If it's not compiled in... because you don't have the header files...
_______________________________________________

Tux3 mailing list

Tux3@tux3.org

http://tux3.org/cgi-bin/mailman/listinfo/tux3

The hard part is actually detecting that in a way that works on all

Linux distros.  Pkg-config is supposed to be that way, but the libxattr

package ignores it.  That's ok because I found a way to hack the compile
_______________________________________________

Tux3 mailing list

Tux3@tux3.org

http://tux3.org/cgi-bin/mailman/listinfo/tux3

Great, that takes care of that then.  But we still should do our duty

and bug the libattr maintainer(s) about playing nice with pkg-config.

Even autoconf wants that, if it can get it.
Regards,
Daniel
_______________________________________________

Tux3 mailing list

Tux3@tux3.org

http://tux3.org/cgi-bin/mailman/listinfo/tux3