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: tests to see how ext3 reiserfs 3.6 and jfs survive disk errors.
On Mar 31, 2004 16:00 +0400, Vladimir Saveliev wrote: On Wed, 2004-03-31 at 15:44, Ivan Ivanov wrote: I made some tests to see how ext3 reiserfs 3.6 and jfs survive disk errors. The test is simple: format a partition, copy the kernel source, unmount and and do ?dd if=/dev/zero of=/dev/hdd bs=512 count=10 seek=3? to simulate a disk surface damage and then run fsck. seek=3 ? this must be the second half of journal in reiserfs and ext3, for jfs I don't know Well, not that I defend reiserfs's i/o error handling But I do not think that your test is a fair one. You overwrote area where reiserfs stored metadata for data you copied into it. (not sure about jfs, it probably has the same problem). Do you want to try to overwrite ext3's inode tables? Actually, with a 51MB write it is guaranteed to overwrite at least one inode table somewhere in the filesystem (one inode table per 32MB of disk). One of the reasons that ext2/ext3 can survive such actions is that the location of the metadata is in a fixed location so even if everything is overwritten it knows what is inode table, what is data blocks, etc. This makes ext3 less flexible (i.e. no dynamic inode allocation) but also more robust. jfs: total data loss, can't mount, fsck didn't helps reiserfs: - doing ?reiserfsck ?rebuild-tree? moves all recovered data in lost+found, but information is almost unusable ext3: - after ?fsck.ext3 -f -y? almost everything was usable, directory structure was untouched, some files was moved in lost+found, but in general everything was usable. My opinion: I can't use anything but ext2/3 in a system where there is no RAID ? 99% of desktops and most of web and mail servers. If you have time, you may want to try overwriting some other parts of the filesystem, just to see if the results change. I don't think it will make a huge difference in the end, but it might. Note that 51MB is a large fraction of the size of a Linux kernel so you might end up overwriting 1/4 of all the data. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/
Re: tests to see how ext3 reiserfs 3.6 and jfs survive disk errors.
On Wed, 31 Mar 2004 14:44:00 +0300 (EEST) Ivan Ivanov [EMAIL PROTECTED] wrote: I made some tests to see how ext3 reiserfs 3.6 and jfs survive disk errors. The test is simple: format a partition, copy the kernel source, unmount and and do ?dd if=/dev/zero of=/dev/hdd bs=512 count=10 seek=3? to simulate a disk surface damage and then run fsck. seek=3 ? this must be the second half of journal in reiserfs and ext3, for jfs I don't know If you feel destructive please also test with if=/dev/urandom and report how various fscks handle that :) -- Jure Pear
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\_|_/___/
