Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
On Sat, 15 May 2004 14:10:10 +0300, Markus =?UNKNOWN?Q?T=F6rnqvist?= said: This has been discussed. There is the mailer that uses an @-named symlink to the current message. Can't remember which one. That would be MH, nhm, and exmh... pgpVdhLh4Ebv2.pgp Description: PGP signature
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Beni Cherniavsky wrote: Note that changing the magic name (dynamically or even by recompiling) can create a confilict with an *exisiting* file on a reiserfs4 partition (the file could have been created when another name was magic). The FS code should be ready to handle it, preferably giving some escape route way to access the colliding file (e.g. ``foo/my_metas/escape`` could give access to the file known as ``foo/my_metas`` before you changed the magic name to ``my_metas``). That is a very good point, and I think your solution is the right way to get around it. __ Post your free ad now! http://personals.yahoo.ca
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Narcoleptic Electron wrote: Beni Cherniavsky wrote: Note that changing the magic name (dynamically or even by recompiling) can create a confilict with an *exisiting* file on a reiserfs4 partition (the file could have been created when another name was magic). The FS code should be ready to handle it, preferably giving some escape route way to access the colliding file (e.g. ``foo/my_metas/escape`` could give access to the file known as ``foo/my_metas`` before you changed the magic name to ``my_metas``). That is a very good point, and I think your solution is the right way to get around it. __ Post your free ad now! http://personals.yahoo.ca I think we should have a /metasoff hidden directory that presents the filesystem tree but without the metas. Of course, now that we have funding for views, when that is completed you will be able to specify a view that cannot access metas. -- Hans
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Hans Reiser wrote: Of course, now that we have funding for views, when that is completed you will be able to specify a view that cannot access metas. First, congratulations on getting the funding! Second, I'm curious! Would views enable disambiguating conflicted names from plugins? Thanks, John Heintz
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
On Tue, 2004-03-30 at 14:22, Scott Young wrote: by putting a / at the end of their name. Folders are more complicated, but I think it should be done by just adding a slash after the full directory name (full as in including a trailing slash, so therefore there would be two slashes at the end to access an attribute). /home//attribute would be the an attribute on the home directory. This behaviour would be broken, as you can have many slashes together and they just get collapsed as one. This has been so on unixes for a very long time (try 'ls ' on your system :) A lot of things would break if // suddenly meant something different. -- Stewart Smith ([EMAIL PROTECTED]) http://www.flamingspork.com/ signature.asc Description: This is a digitally signed message part
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
What about meths (short for methods)? Is that a word in any language? Meths is word already in english..
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
camis writes:
What about meths (short for methods)? Is that a word in any language?
Meths is word already in english..
Indeed, meths is plural of meth which is (rare) synonym for a meath,
a mead, Russian m'od:
From Webster's Revised Unabridged Dictionary (1913) [web1913]:
Meath \Meath\, Meathe \Meathe\, n. [See {Mead}.]
A sweet liquor; mead. [Obs.] --Chaucer. Milton.
Nikita.
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
On Tue, 06 Apr 2004 23:05:45 +0400, Nikita Danilov said:
Meath \Meath\, Meathe \Meathe\, n. [See {Mead}.]
A sweet liquor; mead. [Obs.] --Chaucer. Milton.
On the other hand, both those Chaucer and Milton blokes have
been dust for quite some time, and the language has moved on.
Does anybody outside the Renaissance Fair circuit still even drink mead? ;)
pgp0.pgp
Description: PGP signature
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Good point, search engines as evidence. The problem is you're only looking at distributions, which are going to be highly similar and you're completely missing end users. So let us take this to a full search engine and see what turns up... Hmm, roughly a million hits, let us look at a few samples: http://www.metas.ch/ http://vancouver-webpages.com/META/mk-metas.html http://www.metas.com.br/ http://metas.enfermeria21.com/ http://www.metas.com.mx/ Okay, out of one million hits, we randomly look at ten, and half feature metas in the URL somewhere. Going the other direction, Google indexes roughly 4 billion pages. If we guess the above search was representative, roughly 500,000 pages will include metas somewhere in the URL, possibly only as a hostname, but somewhere. So we've managed to collect 1 out of every 10,000 pages that Google indexes. Though we don't have a direct proof, I hope I've come close enough to scare you. Quite true.. ..metas or .metas would be the better choice.. Regards, Cami
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Grant == Grant Miner [EMAIL PROTECTED] writes: Grant You mean /sys/fs/reiser4/metas? :P My /sys doesn't even have a fs subdirectory. So I'm pretty sure I mean /proc (unless you can tell me why it should be in /sys. But AFAICT /sys deals more with accessing hardware properties.). -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
From: Hans Reiser [EMAIL PROTECTED] these problems will not exist significantly in reality. Look at netapps and snapshots and clearcase and other filesystems, I remember wondering if .snapshot could be a problem when netapps were new and it was never a problem. Notice though that that filename begins with ., not a letter. This causes all programs to treat it specially. Also note that that filename is nine characters long, and therefore making a purely random collision less likely by more than four orders of magnitude. People who find it is a problem can #define it to something else. If 5 people bother to do so, I will be surprised. Many languages have reserved keywords. I REJECT THIS! I believe Ada is almost the only programming language without reserved words. The thing is a filesystem is NOT a programming language! It is designed to handle files with arbitrary names, no matter how odd. Only programmers deal with C, end users must deal with filesystem limitations. From: cami [EMAIL PROTECTED] Not sure if anyone has bothered to check if this would impose the limitation that people are worried about. From a quick glance, none of the linux distro's have ever had a file / directory called metas before. `metas` isn't even a real a word anyway (at least not an english word) so the chances of it being a big issue are very very small.. freshmeat.net's search shows not even one hit for the word metas and that pretty much the majority of linux/coding related projects.. Good point, search engines as evidence. The problem is you're only looking at distributions, which are going to be highly similar and you're completely missing end users. So let us take this to a full search engine and see what turns up... Hmm, roughly a million hits, let us look at a few samples: http://www.metas.ch/ http://vancouver-webpages.com/META/mk-metas.html http://www.metas.com.br/ http://metas.enfermeria21.com/ http://www.metas.com.mx/ Okay, out of one million hits, we randomly look at ten, and half feature metas in the URL somewhere. Going the other direction, Google indexes roughly 4 billion pages. If we guess the above search was representative, roughly 500,000 pages will include metas somewhere in the URL, possibly only as a hostname, but somewhere. So we've managed to collect 1 out of every 10,000 pages that Google indexes. Though we don't have a direct proof, I hope I've come close enough to scare you. Hans, what will it take for you to change your mind? -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \ (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_ \ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
The == The Amazing Dragon (Elliott Mitchell) [EMAIL PROTECTED] writes: [...] The Good point, search engines as evidence. The problem is you're only The looking at distributions, which are going to be highly similar and The you're completely missing end users. So let us take this to a full The search engine and see what turns up... Hmm, roughly a million The hits, let us look at a few samples: I'm only getting a bit less than 600,000. Maybe we caught Google in the middle of some reindexing. But anyways... Most of the pages seem to be Spanish and Portuguese. Google translation translates metas as goals. Are there any Spanish or Portuguese speakers on this list to confirm that? Since goals is a fairly common word, it probably is a bad idea to use metas without at least some sort of prefix. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Hans Reiser wrote: Narcoleptic Electron wrote: What is the plan for addressing the name clash problems that this causes? (eg. I copy a directory, that happens to contain a metas directory, to my Reiser4 partition) these problems will not exist significantly in reality. Look at netapps and snapshots and clearcase and other filesystems, I remember wondering if .snapshot could be a problem when netapps were new and it was never a problem. I do not disagree that it is unlikely. However, it is still possible, so my question remains: what happens in the scenario I describe? People who find it is a problem can #define it to something else. If 5 people bother to do so, I will be surprised. True; as long as everyone refers to the metas directory properly (using an environment variable, for example, as opposed to hard-coding the string metas anywhere), it will be fine. Many languages have reserved keywords. We're not talking about a language here, though... we're talking about a namespace. To me, the measure of usefulness of a namespace is the ability to provide names... reserved words hamper that ability. The perfect namespace has no reserved words; at worst, only reserved characters, with escape sequences provided for each so that any name is still possible. __ Post your free ad now! http://personals.yahoo.ca
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Narcoleptic == Narcoleptic Electron [EMAIL PROTECTED] writes: [...] Narcoleptic True; as long as everyone refers to the metas directory Narcoleptic properly (using an environment variable, for example, as Narcoleptic opposed to hard-coding the string metas anywhere), it Narcoleptic will be fine. Hmm. Maybe have a /proc/fs/reiser4/metas file to query it? (Environment variable seems fragile.) -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
On Sunday 04 April 2004 06:28, Hubert Chan wrote: Narcoleptic == Narcoleptic Electron [EMAIL PROTECTED] writes: [...] Narcoleptic True; as long as everyone refers to the metas directory Narcoleptic properly (using an environment variable, for example, as Narcoleptic opposed to hard-coding the string metas anywhere), it Narcoleptic will be fine. Hmm. Maybe have a /proc/fs/reiser4/metas file to query it? (Environment variable seems fragile.) Good idea. Of course, I will be the first one to set it to ... ;-) -- Regards, Christian Iversen
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
I do not disagree that it is unlikely. However, it is still possible, so my question remains: what happens in the scenario I describe? Hi What happens now is open() returns EEXIST (file exists) error; reiser4 can't make the file. Is this what you mean?
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Hubert Chan wrote: Narcoleptic == Narcoleptic Electron [EMAIL PROTECTED] writes: [...] Narcoleptic True; as long as everyone refers to the metas directory Narcoleptic properly (using an environment variable, for example, as Narcoleptic opposed to hard-coding the string metas anywhere), it Narcoleptic will be fine. Hmm. Maybe have a /proc/fs/reiser4/metas file to query it? (Environment variable seems fragile.) You mean /sys/fs/reiser4/metas? :P
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Christian Iversen wrote: On Sunday 04 April 2004 06:28, Hubert Chan wrote: Narcoleptic == Narcoleptic Electron writes: Narcoleptic True; as long as everyone refers to the metas directory Narcoleptic properly (using an environment variable, for example, as Narcoleptic opposed to hard-coding the string metas anywhere), it Narcoleptic will be fine. Hmm. Maybe have a /proc/fs/reiser4/metas file to query it? (Environment variable seems fragile.) Good idea. Of course, I will be the first one to set it to ... ;-) Yes, a /proc/fs/reiser4/metas file containing the meta directory name is a far better approach than putting it in an environment variable (that was just the first thing that came to my mind to demonstrate the point). __ Post your free ad now! http://personals.yahoo.ca
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Elliott Mitchell wrote on Wed, 31 Mar 2004 21:46:14 -0800 (PST): Also I feel it should be on the file itself. ie for the file /tmp/fooblah you should be able to access the file's metadata by open()ing/using readdir() on /tmp/fooblah/metas or (/tmp/fooblah/..metas or whatever). Sounds good to me. I just hope that directory operations are cheap in the file system. The alternative of just adding a ..meta. prefix to all attribute names would cut out one level of directories (less disk space usage, less lookup time to resolve a path, and no worry about the weirdness of attributes accidentally getting attached to the ..metas directory itself). /tmp/fooblah/..metas/mime-type /tmp/fooblah/..metas.mime-type Hmmm. Which is better? The weirdness factor worries me more than the performance reduction. - Alex
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
This discussion is spiralling out of control. There is far too much misunderstanding. A discussion summary is in order. PROPOSALS: 1. Leave the metas directory as it is, for storing the meta data hierarchy. 2. Rename metas to: a) ..metas b) @ c) + 3. Revise the architecture so that instead of putting meta data into a directory, make it accessible via a different path delimiter. Proposals for a delimiter include: a) \ b) @ c) . 4. Return to the original approach of putting meta data files into the parent directory, and prefixing the name with: a) ..metas. PROBLEMS: 1. Name clashes with user files; metas does not have meaning in all non-English languages; too long. 2. Name clashes with user files. a) ..metas does not have meaning in all non-English languages; too long. b) Conflict with an important mail application's directory naming scheme. c) No additional problems. 3. All file names containing the delimiter character will cause problems; introduces a whole new [arguably redundant] fundamental concept. 4. A step backwards; dramatically increases chance of name conflicts (since meta data is no longer in one discrete location, but interspersed with user files). If there are other approaches not addressed here, or clarification required, please feel free to revise this list. __ Post your free ad now! http://personals.yahoo.ca
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
On Thursday 01 April 2004 18:31, Narcoleptic Electron wrote: If there are other approaches not addressed here, or clarification required, please feel free to revise this list. I think someone suggested putting meta file information in /proc. So. Is this a bad idea? I think not. In this scheme, /some/file would have /proc/metas/some/file/* as meta information. This reduces the risk of conflict to 0. One other idea I have, is That way, dir/. is the directory itself dir/.. is the parent and dir/... is the meta info. Any comments? -- Regards, Christian Iversen
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
Hubert Chan wrote: That effectively kills all filenames that contain @, much worse than just a metas conflict IMHO. I strongly agree: - A restricted character in all names is far more likely to impact users than a single restricted name. - Different types of directories, and extra rules for dereferencing their contents, are extra concepts for users to understand... this seems to run counter to what I see as the overarching philosophy of ReiserFS: unifying file system semantics. I think that the meta directory needs to be thought of not as a special directory, but as a normal directory that has a name that is interpreted in a special way by the system. Markus Törnqvist wrote: I'm not sure either what Hans Reiser meant by a macro, does that mean a settable variable? It's a decent compromise, I think. As someone else stated, let's just hope for an inoffensive default. I agree. This name will be used quite frequently in the shell, and ReiserFS will be judged based on this name (eg. if it is too long, if it is ugly, etc.). Case in point: Lisp, which is a phenomenal language that people avoid because it has too many brackets. Same with Perl, that gets complaints because of its heavy use of funny characters. Aesthetics matter. No one in this thread has commented on + as the default meta directory name (one of the final contenders in our previous thread on the subject). Again, the reasons: - Short (one character) - Makes sense in all languages (meaning additional information) - Available on all int'l keyboards Also, a question: are all meta files necessarily pseudo files? Should users be able to put regular files in there to be interpreted as pseudo files? This will help to clarify some things for me. Cheers, N. Electron P.S. I, too, want to reiterate that everyone has done a great job on this file system and it is a remarkable feat of design and computer engineering, and I'm very thankful for your efforts. I only offer my comments because I care! __ Post your free ad now! http://personals.yahoo.ca
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
On Wednesday 31 March 2004 17:58, Narcoleptic Electron wrote: No one in this thread has commented on + as the default meta directory name (one of the final contenders in our previous thread on the subject). Again, the reasons: - Short (one character) - Makes sense in all languages (meaning additional information) I don't agree. It only makes sense if you know that you a searching for additional information. If a novice user encounters a directory called '+' for the first time, not knowing there is meta information available in reiser4, this will result in a bug report, for sure. If I had to choose between '+' and 'metas' I'd go with 'metas'. -- lg, Chris
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
From: Narcoleptic Electron [EMAIL PROTECTED] Hubert Chan wrote: That effectively kills all filenames that contain @, much worse than just a metas conflict IMHO. I strongly agree: - A restricted character in all names is far more likely to impact users than a single restricted name. This is why a couple candidates need to be brought up. Some seem good at first glance, but are really bad choice after a bit of thought. So you're right a badly chosen single character will be really bad. A good choice needs to have minimal impact by being pretty much unused in filenames. A corollary is that a badly chosen directory name will have a horrific impact on users just as much as a badly chosen special character. I think that the meta directory needs to be thought of not as a special directory, but as a normal directory that has a name that is interpreted in a special way by the system. In other words it is special, but it isn't special? You can't have it both ways. metas is a perfectly valid filename on all other filesystems. It is a valid word or partial word in several languages, bad choice. Files/directories begining with . are at least already handled specially by all tools. Names that are valid words are precious, like gold you shouldn't steal them. There is also the problem that things like Apache deliberately filter out access to some files (like ..) because they're magic. By adding another magic filename you've made those harder, at least begining it with . will keep those tools' job easier (and you don't introduce a huge security hole by adding a filesystem). Also I feel it should be on the file itself. ie for the file /tmp/fooblah you should be able to access the file's metadata by open()ing/using readdir() on /tmp/fooblah/metas or (/tmp/fooblah/..metas or whatever). No one in this thread has commented on + as the default meta directory name (one of the final contenders in our previous thread on the subject). Again, the reasons: - Short (one character) - Makes sense in all languages (meaning additional information) - Available on all int'l keyboards Bad choice. Note the lost+found directory found on *all* Unix filesystems. If we need one more option | might be viable. Also, a question: are all meta files necessarily pseudo files? Should users be able to put regular files in there to be interpreted as pseudo files? This will help to clarify some things for me. My impression is, that the metadata appears as normal files and is accessible as normal files. Just gets interpreted in an interesting way. I doubt metadata would have an owner or permissions separate from the file/directory though. I imagine this is similar to Apple MacOS 10, where all files have a mime-type that is accessible as filename/mime-type. -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \ (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_ \ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
