Re: reiser4progs-1.0.3 : superblock backups
On Wednesday 15 December 2004 21:30, [EMAIL PROTECTED] wrote: > Regarding the new release of reiser4progs: > > it's unclear to me from the release announcement whether prevoius versions > of reiser4progs correctly backup superblocks or not. You imply it's been > corrected - so it wasn't working before? blocks were reserved but the content was not correct. > i.e. if I had previously used libaal 1.0.2, and my superblock got > corrupted, could I rebuild it from teh backup if upgarded to 1.0.3? no, backup will not be found. both versions will recover the super block in the same way -- 1.0.2 does not take the backup into account at all; 1.0.3 will not find the backup on your fs -- however 1.0.3 will also fix the backup. > I'm asking because recently that's exactly what happened to me. My disc is > failing due to hardware level problems, the superblock is wrecked, it won't > mount, and I need to recover my stuff! > > In a final rescue effort, I've updated to 1.0.3, but if I run fsck.reiser4 > --build-sb, I get: > > [...] > Warn : A new master superblock is created on '/dev/hdd1'. > Enter the key plugin name [key_large]: > Error: Can't read bitmap block 18. Input/output error. > Error: Can't load ondisk bitmap. > Error: Can't initialize block allocator. > Fatal: Failed to open the block allocator. io error on the block # 18 (4k size). > Can anyone tell me what it means? Is the problem to do with reiser4 > superblocks or is the disk so buggered it can't write the table anymore? it looks like the disk problem, look into your syslog for more info. > Any help is greatly appreciated... > > Luciano > > p.s. shame I'm having these hardware problems, as besides that r4 has > worked pretty well! -- Thanks, Vitaly Fertman
Message subject
2005 United States Healthcare & Dentist directory Database This complete database includes all hospitals, nursing homes, and physicians and Dentist in the country. In a rapidly-changing industry, current healthcare information is an invaluable resource to businesses and organizations. The United States Healthcare Database includes comprehensive information on more than 7,000 hospitals, 25,000 nursing homes and 400,000 doctors. It is the most extensive and reliable mailing list and database of key decision makers in the health care market. (New Dentist directory, dental practice, dental labs, cosmetic dentists, DDO, dental care directory, directory of dentists, dentist CD, dentist lists, orthodontists, periodontology, oral surgeons, dental lists, tooth decay, dental products, gum disease, oral health, genral practice, dental directory.) >From our previous customer feedback, this directory is found to be the leading source of dentist reference in the United States. It is used by professionals and industry business development executives who must communicate with dentists in an efficient and timely manner.. The American Directory of Dentists contains relevant data on over 200,000 dentists in the United States. Each record is indexed by such features as name, address, phone/fax, county, year licensed, type of practice, type of dentist as well as specialty. === Each record is indexed by such features as name, address, phone and fax. The database is available in Excel format on CD Rom. It is designed for mailing lists and merges. The data can be selected by state or other criteria such as type of practice. It can be used on an unlimited basis. === For the past 14 years, MedCom has maintained the most comprehensive healthcare lists. Our directories are 100% telephone verified and updated every quarter. MedCom continues to hold the nation's most extensive and reliable databases of key decision-makers in the health care market. For a limited time, this extensive database is offered at an introductory. The United States Healthcare Database and The American Directory of Dentists Price of $195 (reg. $745). To order, please print this e-mail, complete the information below and fax it to 416-765-0029 (tel: 416-765-0028). NAME: TITLE: ORGANIZATION: ADDRESS: CITY: STATE: POSTAL: TEL: FAX: EMAIL: If you want to use Paypal we can Request money from your Paypal Account: Or wire money from your Bank to our Bank. Please call us @ 416-765-0028 for details. We also accept money orders, cashier's checks, & personal checks. IF YOU ARE MAKING A PAYMENT BY CHECK (money order, cashier's check) MAIL TO. MedCom 4410 Massachusettes Ave. NW, #201 Washington, DC 20016 You received this message ONLY ONE TIME
Re: file as a directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Foldiak wrote: | On Wed, 2004-12-15 at 04:47, David Masover wrote: | |>Peter Foldiak wrote: |>| Also, a pseudofile (e.g. dirname//structure ?) could be used to |>| specify how the files should be glued together. A simple question is, |>| for instance, what separators to use between the components, and what |>| ordering to use when putting the component objects together. (This |>| pseudofile could also determine more complicated ways of composing |>| objects.) |> |>If the filesystem does caching, I'd rather have a type of executable |>which, read normally, appears as a stream of its own standard output. |>You'd get the actual file as something like bar/.../source. | | | This sounds better and more general than my proposed /structure | file. So could you explain this in a bit more detail? | Would for instance the simplest (and default?) glueing code in your | bar//source file be | | cat * | | which just concatenates all the subcomponents in no particular order? Sounds right. Well, actually, you need a shebang, as this would be called from kernel space. Speaking of which, how much speed is lost by starting up a process? The idea of caching is that running cat *; cat *; cat *; cat *; cat * is probably slower than cat * > baz; cat baz; cat baz; cat baz; cat baz; cat baz The kernel is the right place to do such caching. It is not the right place to implement almost any kind of "cool new kind of file" that Hans wants us to develop. |>This could be done with pipes and daemons, but it's not as easy to |>manage and seems impossible to do as efficiently (with built-in caching, |>etc.) | | | How would you do it? With two kernel reiser4 plugins -- one for files and one for directories. Others could come later, but I don't see this being so important for things like symlinks. Then, I'd let reiser4 cache things (in RAM and in free space on the filesystem) which are generated through these plugins. Directory plugins allow inheritence, too -- just have the plugin install itself on all of its children. Compression, encryption, etc. could all be done through the same mechanism. [...] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQcDPO3gHNmZLgCUhAQIYhg//VeuJvEG2cbwANaka136xXDSy5blo71f0 ulgVBIe7XK8SMpLigNwVQQlTpmIncccu4ymOZG8egf4ex9d269Zv47TSmP+QkJEi UU8Oky+oMFE/ntg5ZEoVxXe+oz2fCxzyYKwyjdWwHJZnylsHSaSsIpziaIZR+UXG hcxZ9Cs3sLSlK0iYWM/R3dFBgRDMKR3/spz9gHGtyicLYbGvhzdHo6jSE1V8bqrg 44gt3XbB/SgKQTSeqBMr2/QCPpHKrFKqFhrsbVNzcjL7GftLOBeGRvVAWF9QIlUv qDbIubfchr2KxYxE8qCsKTYqX5+VgDj0GDuwuymiq7fy4cIO0VIr3br1vJRWDUy3 VZeTbrQd3LJ6gSiTPN8+0CQQlpjEduS5EZfeIiygrQed1xHZBUbR59xV7KfIaHLz lY06VKpwstmPjHueNx9T7T18aOjMVLWZbA+IWbRHdqLs0VqNltttVIz0e8WgFJHJ 3ISA0N+WNYCeR75XjWnD78e6vzhvTlGKLe2PjAdWDtuiSKTITV1HCKjSzMFL3JEd CymOFhxddxx+aZrd8w1s0unjdGzkxdPfmpdd0XdBnB7vHYPpkw4ELacIqHt0OOTg UYnBMem/UhLxisllfBOc0lunbxFynPOjsqYFTDTcHYHoZh0Kyel98m25uXeEr9VL m2R6SMkl49k= =oNG7 -END PGP SIGNATURE-
Re: file as a directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans Reiser wrote: [...] | Explain the value of caching executable output more please. If executables become "plugins" (see below), there is a performance loss to be made up by caching. For instance, if we have an executable which calls "tar", which we attach to a tarball, we want to cache the extracted files. It's even more urgent when people start writing perl/python/ruby executables to deal with system configuration files, such as /etc/passwd. It's allright for passwd to take half a second to generate, so long as we cache that output, and thus only spend the half second when passwd is modified, instead of every time a user logs in. | |> |> | The component objects themselves could be full objects, so they |> | themselves could have sub-components. |> |> Right. |> |> Also, there should be an inverse. For instance, a file-as-directory type |> object should have a "contents" object, usually a normal directory, but |> which could conceivably be any type of object, including a code-ish |> object which implements a filesystem. Accessing foo/ would be the same |> as accessing foo/.../contents, only because "..." (or whatever we use |> for meta-files) is outside the actual directory namespace, |> foo/.../contents/... refers to the metas of object "contents", which are |> different than the metas of object "foo". | | | Are you sure that having more than one "" is needed? Hmmm, | interesting, must think about it. Yes. foo is a file, foo/contents is another file (an executable). But maybe the executable has contents too -- with an extra "...", you can do things like "foo/.../contents/.../contents", where the first "contents" controls what you get from "ls foo/", and the second "contents" controls what you get from "ls foo/.../contents/". |> |> These two steps essentially create userspace "plugins", and do away with |> having to mount other kernel layers such as lufs (or whatever its |> current implementation is). | | | I don't follow this point above. lufs is (or was) a kernel filesystem which talks to a user daemon. The daemon does all the work, so you don't have to do things like windows emulation in the kernel in order to get captive-ntfs to work. The reason we don't do that for the whole filesystem is performance -- after all, userland things are easier to write, debug, upgrade, and install/use than kernel things. If an executable can generate a directory listing or a whole directory structure, some files, and so on, then we only need a few reiser4 kernel plugins, and these userland executables can implement all the functionality of most kernel plugins people have thought of so far. The only problem is, it would be much slower than a kernel plugin. Caching solves that. Of course, someone still might find a situation where people really need to create a new kernel plugin, and that would be allowed. But I doubt it would help that much, or we'd all be using TUX instead of Apache. [...] |> I think the issues with directory-as-a-file were the same problems you |> get when you allow hardlinked directories -- that you'd eventually have |> to ditch reference counting for a garbage collector, which is hellishly |> impractical. I don't have a solution to that, other than dropping |> hardlinks entirely. | | | This issue is overblown. Other fields have solved this problem. Nevertheless, it's an issue that I don't have the skills to solve, and one that must be solved if we are ever to implement these concepts. If you have a solution, I'd love to hear it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQcDT93gHNmZLgCUhAQLn6g/+KXD5StI9m9Tpij0i3uwqXAc+oAdz/dX5 YHSwU7YYXSdVPPqNqUNnU4t7i8M1p8Mba0Jpc2rPZk6Is67txBnphLX2F7c9jLm8 wfqfkjrfOM7/+5/EDQbdGVch0gZnuLJrxjGcpvukkwi8hkiMQnOtZuKuZwn1ieMW UlTy5e/IhDPl5zW/Dy3rpoAOw7hszvPv6fjpFDujUENHhhUQmWYoiIbIaV3rdbhY De+9AOkCRDEYNOmreCQQYmTkJD6w4C9cHzqmx7FrVx8vhxU3k9CPwoGRGGIrn42+ UPKAtUCAZu6Mya1v9v6QnPFaqnPgQatIJl4edg91bBzktpRZg6oR2iS9QnnAxc+b LFJr95OKtdjBVVNuJGLRVCi06xoQsIjNWe5rOajAGHw/YHr7mHMZF315XKcp7FPa F1df8FwdpQgq2xM6OdIfSFlBxk2poj21w5NqVyOZoEMunTyyDnK0YQkigsz2AQeN lOeryopJ1sh9eHkQOsxOh/JdpYCVSkOfWiPgDKMst9mZbFF4yWwsot9JP1rNIUOC EtGHdQzUOtKPkKWNy2+VXKxd8F+5EUpAtmOrdG2B7FT0wjS5Ao1pz6c7boMo1x9D +9QxS2W1DdWjsCR9WhZhg0+eWc2wkf/dyVQIipf3JTm5vLOFJvJ/jfV3GRg0Ye7f gtjTMcGxzAc= =CIsH -END PGP SIGNATURE-
Re: file as a directory
Markus Törnqvist wrote: On Wed, Dec 15, 2004 at 08:57:27AM -0800, Hans Reiser wrote: www.namesys.com/future_vision.html 404. http://www.namesys.com/whitepaper.html oops. Thanks.
Re: Reiser4 and ZFS
On Tue, 14 Dec 2004 22:46:08 PST, Job Bob said: > So if ZFS is not the vaporware that WinFS is, what > new features of ZFS are worth incorporating into > Reiser fs? Will Reiser fs continue to stay ahead of > ZFS? This of course depends in a *large* part on how exactly you define "ahead". For many shops, it's quite likely that a ZFS with "more scalability and administration" is The Right Choice, especially if it does *NOT* include lots of odd new features and quirks that might break production code (remember the joys in getting Apache running on reiser4, until it was discovered that the 'file-as-directory' stuff broke programs that weren't expecting it?). The criteria I use for rating a filesystem as being "ahead" for use on my laptop (where new cool features often count for more than stability or performance) are very different than what I want for a mail server. And the guy 3 cubicles over doesn't *care* about the details of filesystems - he just worries about "will this make Oracle run faster or more robustly?". pgpcwdXJGglKy.pgp Description: PGP signature
Re: file as a directory
On Wed, Dec 15, 2004 at 08:57:27AM -0800, Hans Reiser wrote: >www.namesys.com/future_vision.html 404. http://www.namesys.com/whitepaper.html -- mjt
reiser4progs-1.0.3 : superblock backups
Regarding the new release of reiser4progs: it's unclear to me from the release announcement whether prevoius versions of reiser4progs correctly backup superblocks or not. You imply it's been corrected - so it wasn't working before? i.e. if I had previously used libaal 1.0.2, and my superblock got corrupted, could I rebuild it from teh backup if upgarded to 1.0.3? I'm asking because recently that's exactly what happened to me. My disc is failing due to hardware level problems, the superblock is wrecked, it won't mount, and I need to recover my stuff! In a final rescue effort, I've updated to 1.0.3, but if I run fsck.reiser4 --build-sb, I get: [...] Warn : A new master superblock is created on '/dev/hdd1'. Enter the key plugin name [key_large]: Error: Can't read bitmap block 18. Input/output error. Error: Can't load ondisk bitmap. Error: Can't initialize block allocator. Fatal: Failed to open the block allocator. Can anyone tell me what it means? Is the problem to do with reiser4 superblocks or is the disk so buggered it can't write the table anymore? Any help is greatly appreciated... Luciano p.s. shame I'm having these hardware problems, as besides that r4 has worked pretty well!
Re: file as a directory
Horst von Brand wrote: Hans Reiser <[EMAIL PROTECTED]> said: Horst von Brand wrote: Peter Foldiak <[EMAIL PROTECTED]> said: [...] Perhaps a better way to think about this is that instead of talking about directories and files, we just talk about objects. Then you have a collection of interrelated objects, i.e., a database. Operating systems that work on databases (no filesystem) have been done, and are a nice idea... but are far, far away from Unix. A journey of a thousand leagues begins with a single step. Right. But you need to know where you are going, and why. Actually, databases are the wrong solution because they are relational, Says who? Read the www.namesys.com/future_vision.html paper for why relational is the wrong model. and what is needed is a semi-structured query language that is upwardly compatible with Unix hierarchical semantics, ala www.namesys.com/future_vision.html
Re: Reiser4 and ZFS
On Wed, Dec 15, 2004 at 10:27:41AM -0600, Chris Cox wrote: > ZFS is vaporware at the moment. A marketing blurb, > not a released product. An alpha version will probably > come for Solaris 10 about mid year... not sure when > it will be "blessed" for production use. Isn't ZFS yet released as part of Solaris 10?
Re: Reiser4 and ZFS
Job Bob wrote: ... So if ZFS is not the vaporware that WinFS is, what new features of ZFS are worth incorporating into Reiser fs? Will Reiser fs continue to stay ahead of ZFS? ZFS is vaporware at the moment. A marketing blurb, not a released product. An alpha version will probably come for Solaris 10 about mid year... not sure when it will be "blessed" for production use. Folks closer to Sun are welcome to correct my assessment.
Re:
Внимание акция! Закажи до 2О дekaбря Е-Mail paccылку и получи бoнyc(paccылкy по icq) (О95)IО9-57О6 [EMAIL PROTECTED] icq 283673170
Re: Status of quota support for reiserfs on 2.6.x kernels
Hello!
> Christian Mayrhuber gmx.net> writes:
>
> > Quotas are in kernel 2.6 and supported by ext2,ext3,reiserfs,xfs.
> > Reiserfs doesn't need an extra patch for quotas, data journalling
> > or extended attributes. Everything is right there for
> > kernels > 2.6.5 if I remember right.
>
> I tried to use quota with 2.6.7 and got two serious problems:
I suggest trying some newer kernel - either 2.6.10-rc3-mm1 or
just plain 2.6.10-rc3 with attached patch applied (the patch fixes the
deadlock you seem to hit).
> 1. soft quotas were treated like hard quotas
> (grace time 8 days but behaved like 0 days)
That is rather strange - I never heard about such problem. If this
problem remains after changing the kernel then mail me please and we try
to sort that out.
> 2. after a few days no access to the file system was possible,
> fs-options usrquota and grpquota were doubled
> when listed by the mount command.
> (all 14 clients, samba and nfs paralyzed,
> a whole radio station silent, yes I had better days)
> After reboot the problem was gone but I turned quota off.
That looks like a deadlock which should be fixed by now.
Honza
diff -rupX /home/jack/.kerndiffexclude linux-2.6.10-rc2/fs/dquot.c
linux-2.6.10-rc2-quotafix-all/fs/dquot.c
--- linux-2.6.10-rc2/fs/dquot.c 2004-11-16 16:39:07.0 +0100
+++ linux-2.6.10-rc2-quotafix-all/fs/dquot.c2004-11-23 18:10:29.470754136
+0100
@@ -49,7 +49,7 @@
* New SMP locking.
* Jan Kara, <[EMAIL PROTECTED]>, 10/2002
*
- * Added journalled quota support
+ * Added journalled quota support, fix lock inversion problems
* Jan Kara, <[EMAIL PROTECTED]>, 2003,2004
*
* (C) Copyright 1994 - 1997 Marco van Wieringen
@@ -75,7 +75,8 @@
#include
#include
#include
-#include
+#include
+#include
#include
@@ -114,7 +115,7 @@
* operations on dquots don't hold dq_lock as they copy data under dq_data_lock
* spinlock to internal buffers before writing.
*
- * Lock ordering (including related VFS locks) is following:
+ * Lock ordering (including related VFS locks) is the following:
* i_sem > dqonoff_sem > iprune_sem > journal_lock > dqptr_sem >
* > dquot->dq_lock > dqio_sem
* i_sem on quota files is special (it's below dqio_sem)
@@ -183,8 +184,7 @@ static void put_quota_format(struct quot
* on all three lists, depending on its current state.
*
* All dquots are placed to the end of inuse_list when first created, and this
- * list is used for the sync and invalidate operations, which must look
- * at every dquot.
+ * list is used for invalidate operation, which must look at every dquot.
*
* Unused dquots (dq_count == 0) are added to the free_dquots list when freed,
* and this list is searched whenever we need an available dquot. Dquots are
@@ -1314,10 +1314,14 @@ int vfs_quota_off(struct super_block *sb
{
int cnt;
struct quota_info *dqopt = sb_dqopt(sb);
+ struct inode *toputinode[MAXQUOTAS];
+ struct vfsmount *toputmnt[MAXQUOTAS];
/* We need to serialize quota_off() for device */
down(&dqopt->dqonoff_sem);
for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
+ toputinode[cnt] = NULL;
+ toputmnt[cnt] = NULL;
if (type != -1 && cnt != type)
continue;
if (!sb_has_quota_enabled(sb, cnt))
@@ -1337,14 +1341,50 @@ int vfs_quota_off(struct super_block *sb
dqopt->ops[cnt]->free_file_info(sb, cnt);
put_quota_format(dqopt->info[cnt].dqi_format);
- fput(dqopt->files[cnt]);
+ toputinode[cnt] = dqopt->files[cnt];
+ toputmnt[cnt] = dqopt->mnt[cnt];
dqopt->files[cnt] = NULL;
+ dqopt->mnt[cnt] = NULL;
dqopt->info[cnt].dqi_flags = 0;
dqopt->info[cnt].dqi_igrace = 0;
dqopt->info[cnt].dqi_bgrace = 0;
dqopt->ops[cnt] = NULL;
}
up(&dqopt->dqonoff_sem);
+ /* Sync the superblock so that buffers with quota data are written to
+* disk (and so userspace sees correct data afterwards).
+* The reference to vfsmnt we are still holding protects us from
+* umount (we don't have it only when quotas are turned on/off for
+* journal replay but in that case we are guarded by the fs anyway). */
+ if (sb->s_op->sync_fs)
+ sb->s_op->sync_fs(sb, 1);
+ sync_blockdev(sb->s_bdev);
+ /* Now the quota files are just ordinary files and we can set the
+* inode flags back. Moreover we discard the pagecache so that
+* userspace sees the writes we did bypassing the pagecache. We
+* must also discard the blockdev buffers so that we see the
+* changes done by userspace on the next quotaon() */
+ for (cnt = 0; cnt < MAXQUOTAS; cnt++)
+
Re: file as a directory
Hans Reiser <[EMAIL PROTECTED]> said: > Horst von Brand wrote: > >Peter Foldiak <[EMAIL PROTECTED]> said: > >[...] > >>Perhaps a better way to think about this is that instead of talking > >>about directories and files, we just talk about objects. > >Then you have a collection of interrelated objects, i.e., a database. > >Operating systems that work on databases (no filesystem) have been done, > >and are a nice idea... but are far, far away from Unix. > A journey of a thousand leagues begins with a single step. Right. But you need to know where you are going, and why. > Actually, databases are the wrong solution because they are relational, Says who? > and what is needed is a semi-structured query language that is upwardly > compatible with Unix hierarchical semantics, ala > www.namesys.com/future_vision.html -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
Reiser4 and Wine
Hello! There are some problems with Wine and Reiser4. According to, http://bugs.winehq.org/show_bug.cgi?id=2525 the problems are solved in Wine CVS. I can't confirm it because I didn't have the time to try it myself, maybe over weekend. I would like to know what is the cause of problems with Wine+Reiser4 when working with file selector dialogs? Thanks! Best regards, Ljubo -- Linux User #277235 Linux Machine #205191 Gentoo Linux, 2.6.9-shadow, Reiser4 GnuPG key #72169511 @ hkp://subkeys.pgp.net pgpbOvUJ5OHbh.pgp Description: PGP signature
Re: file as a directory
On Wed, 2004-12-15 at 04:47, David Masover wrote: > Peter Foldiak wrote: > | Also, a pseudofile (e.g. dirname//structure ?) could be used to > | specify how the files should be glued together. A simple question is, > | for instance, what separators to use between the components, and what > | ordering to use when putting the component objects together. (This > | pseudofile could also determine more complicated ways of composing > | objects.) > > If the filesystem does caching, I'd rather have a type of executable > which, read normally, appears as a stream of its own standard output. > You'd get the actual file as something like bar/.../source. This sounds better and more general than my proposed /structure file. So could you explain this in a bit more detail? Would for instance the simplest (and default?) glueing code in your bar//source file be cat * which just concatenates all the subcomponents in no particular order? > This could be done with pipes and daemons, but it's not as easy to > manage and seems impossible to do as efficiently (with built-in caching, > etc.) How would you do it? > > | The component objects themselves could be full objects, so they > | themselves could have sub-components. > > Right. > > Also, there should be an inverse. For instance, a file-as-directory type > object should have a "contents" object, usually a normal directory, but > which could conceivably be any type of object, including a code-ish > object which implements a filesystem. Accessing foo/ would be the same > as accessing foo/.../contents, only because "..." (or whatever we use > for meta-files) is outside the actual directory namespace, > foo/.../contents/... refers to the metas of object "contents", which are > different than the metas of object "foo". > > These two steps essentially create userspace "plugins", and do away with > having to mount other kernel layers such as lufs (or whatever its > current implementation is). It does have one important implication, though: > > It's important that "metas" or "..." or whatever we've decided on should > _not_ be mutable by a "userspace" plugin that I have described, nor > should any meta-files created by kernel plugins. There would be other > security implications, of course -- user should still not be able to > create files that are owned by other users and setuid. I'm not sure > where such checks should go, but we want mortal users to be able to add > whatever plugins they want, while super-users can feel safe using the > metas interface to manipulate user files. Sounds really interesting.
