Re: Reiserfsck --rebuild-tree rendered machine unbootable.
Hello On Thu, 2004-09-16 at 03:53, Steve Milo wrote: > Hello, I was trying to erase some files in /var/run/sysconfig and > /var/run/smpppd on my Suse 9.1 box. Logged in as root I would get 'permission > denied' when 'ls -l' or 'rm -f'. > I figured perhaps the filesystem had become corrupted somehow so I decided to > do a reiserfsck --rebuild-sb. That didnt fix what I persumed was a > permissions issue. > I then ran a reiserfsck --rebuild-tree and it found quiet a few problems and > appeared to have fixed them. I decided to reboot and found that my machine > was rendered unbootable. It goes into grub and I can get a grub prompt but I > receive 'hd(0,0) wrong filesystem' or something to that effect. > I did not make a backup copy of my filesystem like I should have, I figured I > could get away with not doing so. I guess I was wrong. > > Any help in this matter would be appreciated. > Did you try to boot of Suse 9,1 disk and to recover? > Thanks, > Steve M > > -- > Open WebMail Project (http://openwebmail.org) > >
Re: Reiser4 support on parted program ...
Dr. Giovanni A. Orlando wrote: Yury Umanets wrote: Hans Reiser wrote: Dr. Giovanni A. Orlando wrote: As soon the installer works fine supporting Reiser4, including parted support it, I will comment in this mailing list, and offer for free donwload. Reiser4 resizer is not ready for prime time, and like pseudos, should not have been enabled before it was tested. We are going to send in a patch to turn it off until it is debugged. hello Hans, I suspect, that Dr. Giovanni A. Orlando meant offline resizer which should be in utils. Not online resizer-repacker... Actually, we want that reiser4 is supported inside parted program. Nothing else. I don't think this support will enable any other support like reiser4-resize. One of options provided by parted is offline resizing though... Thanks, Giovanni -- umka
Re: EACCESS vs ENOENT for nonexistent files-within-files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nikita Danilov wrote: > evilninja writes: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > Hello, Christian evilninja :) um, yes, it just sticks ;-) > > But in reiser4 file.txt _is_ a directory. That's the whole point: it > contains other objects inside. [...] > This is very simple: do be able to do a lookup one needs +x bit. No +x > bit--no lookup. No lookup---impossible to determine exists .htaccess or > not. ok, so things will be different when i'll try reiser4 on my box. > Permission bits determine what operations are possible on > object. Letting user to know that .htaccess doesn't exist while > permission bits on parent explicitly disable lookups is a security > hole. yes, i think i got i now. thanks for the explanation. Christian. - -- BOFH excuse #65: system needs to be rebooted -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBSNerC/PVm5+NVoYRAuLsAJ99JCbKQ0ebl9xRPwwYK/un9OKRtgCg3nOu tlYw+GkQWwO2Kfk1pEVlivE= =5iJg -END PGP SIGNATURE-
Re: Sun's ZFS Annoucement
Russell Leighton wrote: Hans was worried about MS and Apple...how about Sun? I'd be curious to hear compare/contrast of ZFS vs other filesystems. Anyone actually touched this in the real world? See: http://www.sun.com/2004-0914/feature/ Ecc is a good idea, and a plugin for it for reiser4 would be interesting, but I am still far more worried about Apple and MS. They plan on making serious attempts at innovation.
Sun's ZFS Annoucement
Hans was worried about MS and Apple...how about Sun? I'd be curious to hear compare/contrast of ZFS vs other filesystems. Anyone actually touched this in the real world? See: http://www.sun.com/2004-0914/feature/
Reiserfsck --rebuild-tree rendered machine unbootable.
Hello, I was trying to erase some files in /var/run/sysconfig and /var/run/smpppd on my Suse 9.1 box. Logged in as root I would get 'permission denied' when 'ls -l' or 'rm -f'. I figured perhaps the filesystem had become corrupted somehow so I decided to do a reiserfsck --rebuild-sb. That didnt fix what I persumed was a permissions issue. I then ran a reiserfsck --rebuild-tree and it found quiet a few problems and appeared to have fixed them. I decided to reboot and found that my machine was rendered unbootable. It goes into grub and I can get a grub prompt but I receive 'hd(0,0) wrong filesystem' or something to that effect. I did not make a backup copy of my filesystem like I should have, I figured I could get away with not doing so. I guess I was wrong. Any help in this matter would be appreciated. Thanks, Steve M -- Open WebMail Project (http://openwebmail.org)
Re: EACCESS vs ENOENT for nonexistent files-within-files
daniel.poelzleithner wrote: Nikita Danilov wrote: | > attributes? Even if the file is world readable? Does this really make sense? | | To make things clear: I have described in my message how things actually | do work in reiser4, so I don't see the point of your questions. If you | think reiser4 semantics is wrong (I am not happy with it too, by the | way), propose to Namesys something better. I would suggest to allow lookups when the user can read the file. The x bit should remain for exec on file objects, because console would be pain when every file must have a exec bits to access meta data. When the user can read a file, i don't think that the meta data can be security risk, he has already access to the file. And therefor not write access to file/metas without +w. No, its not perfect, but i think more unix like than +x for lookups on files.] I like this for access to the builtin metafiles (whose permissions should normally be determined not individually but pased on the plugin and its permissions, but what about files within file-directories? For them I think we need to allow sys_reiser4 to change the bits independently, and for apps that don't know how to distinguish the 2 bits, oh well, change one change the other. What are your thoughts? regards ~ Daniel
Benchmark : ext3 vs reiser4 and effects of fragmentation.
I've spent the last 2 days coding and running benchmarks on the effects of fragmentation on both ext3 and reiser4 performance. Explanation and source code is at http://www.willsmith.org/opensource/reiser4/fragperf/ Results and graphs are at http://www.willsmith.org/opensource/reiser4/fragperf/test1/ Dataset is a kernel source (~200Mb) in a small 350Mb partition, with random deletes, copies and overwrites to cause fragmentation. In conclusion: 1) reiser4 is slightly faster than ext3 in some cases, but much faster in others (no surprise). However, deletes are slightly slower. 2) ext3 degrades badly from fragmentation when running ordered (non-random) access patterns. reiser4 also degrades but not as much. 3) the repacker can bring performance of reiser4 back to full speed, but only if run several times. 4) the repacker is not yet stable - I had to run fsck a few times after repacking, and once got a kernel stack trace during repacking resulting in an un-unmountable filesystem. I'll gladly rerun with different parameters and/or change the script if requested. Will Smith
YET another problem in committing old transactions
Hi,
There is one more problem in committing the old transactions.
In function reiserfs_flush_old_commits(), there is a condition that checks
if the current transaction is older than 30 seconds. Only if that
condition satisfies, the data is flushed to the disk. The condition looks
like:
if (blah blah blah &&
(now - SB_JOURNAL(p_s_sb)->j_trans_start_time) >
SB_JOURNAL_MAX_TRANS_AGE(p_s_sb))
{
/*flush the transaction by calling do_journal_end*/
}
Note: SB_JOURNAL_MAX_TRANS_AGE(p_s_sb) returns 30 seconds.
Now my question is this:
When does reiserfs flush the old uncommitted data ? Is it every 5 seconds
or every 30 seconds ?
If it is going to do it in every 5 seconds when the thread wakes up, why
do we have the condition for 30 seconds ? If the flush happens only every
30 seconds, why the thread calls reiserfs_flush_old_commits() every 5
seconds ?
Is there any reason for this discrepancy ?
Vijayan
Another bug in commiting old transactions
Hi,
This is in continuation to my previous mail on bug in
reiserfs_journal_commit_thread().
Previous bug:
---
There is an "if" condition in reiserfs_journal_commit_thread():
if (CURRENT_TIME - last_run > 5) {
reiserfs_flush_old_commits(s);
}
that must be changed to
if (CURRENT_TIME - last_run >= 5) {
reiserfs_flush_old_commits(s);
}
New bug:
--
Even after changing the above "if" condition to use ">=" instead of
">", dirty old data were not being flushed by the file system. The
reason for this in reiserfs_flush_old_commits() function.
There is a safety check in reiserfs_flush_old_commits(). It looks like:
/* safety check so we don't flush while we are replaying the log during
* mount
*/
if (list_empty(&SB_JOURNAL(p_s_sb)->j_journal_list)) {
return 0 ;
}
This condition was added so that the reiserfs doesn't flush dirty data
while replaying during mount.
But the first transaction after the mount does NOT get flushed to the
disk because of this condition. The first transaction gets added to
the j_journal_list only in function do_journal_end(). So, until that
point the j_journal_list remains empty.
Fix:
Actually, we don't need this condition at all.
reiserfs_flush_old_commits() function will be called only ONLY by the
reiserfs_journal_commit_thread. And this thread is created only after
the replay is over (in journal_init() function). So, I thought even
removing this condition would not affect the system in any way.
Chris: Any comments on this fix ? If you think it is ok, can you
please add this also to your patch ?
I appreciate your help.
Vijayan
RE: silent semantic changes with reiser4
> > I'm probably not the first to suggest this idea, and it's probably not a > very good idea, but here's my idea anyhow: > > You have a file "/usr/bin/emacs" > with a metadata property in the overlaid namespace > "/usr/bin/emacs/[[..]metas/]icon" > > According to some, this could cause some confusion. Howabout instead: > > You have a file "/usr/bin/emacs" > with a metadata property in a slightly separated namespace > "/metas/usr/bin/emacs/icon" > Timothy, see my similar proposal at http://marc.theaimsgroup.com/?l=reiserfs&m=109511131923831&w=2 which viro vetoed. I suspect this horse is quite dead. David
Re: BUG in Reiserfs Journal Thread
I'm using reiserfs 3.6 with the data journaling patch from ftp://ftp.suse.com/pub/people/mason/patches/data-logging/2.4.25/. On Wed, 15 Sep 2004 16:07:16 -0400, Chris Mason <[EMAIL PROTECTED]> wrote: > On Wed, 2004-09-15 at 16:02, Vijayan Prabhakaran wrote: > > Dear Chris Mason, > > > > I found a bug in Reiserfs journal thread. This bug is in function > > reiserfs_journal_commit_thread(). > > Hi, > > Which version of the code are you reading? > > -chris > >
Re: BUG in Reiserfs Journal Thread
On Wed, 2004-09-15 at 16:02, Vijayan Prabhakaran wrote: > Dear Chris Mason, > > I found a bug in Reiserfs journal thread. This bug is in function > reiserfs_journal_commit_thread(). Hi, Which version of the code are you reading? -chris
BUG in Reiserfs Journal Thread
Dear Chris Mason,
I found a bug in Reiserfs journal thread. This bug is in function
reiserfs_journal_commit_thread().
I'm trying to measure the impact of journal thread on data flushes. I
changed the commit interval from the default of 5 seconds (this value
is hard coded in the function) to other different values. I found that
irrespective of changing the journal thread's timer value, the dirty
data was not getting flushed after the time out at the commit thread.
The reason for this is due to a bug in the code. The code looks like
while(1) {
/*blah blah blah*/
if (CURRENT_TIME - last_run > 5) {
reiserfs_flush_old_commits(s);
}
/*blah blah blah*/
interruptible_sleep_on_timeout(&reiserfs_commit_thread_wait, 5 * HZ) ;
/*thread wakes up*/
}
If you see the code, the thread sleeps for 5 seconds. But after waking
up, it again checks the condition:
if (CURRENT_TIME - last_run > 5) {
reiserfs_flush_old_commits(s);
}
Actually, the condition should be ">=" instead of ">". Since the
thread wakes up immediately after the timer expires, the condition
will never satisfy if it is ">".
Chris, can you please verify this and add the fix ?
I appreciate your help.
Vijayan
Re: Error in compiling application program including reiserfs header files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sachin Durge wrote: | Hi All | I am new to this list | I am writting a user application . | In my application i have included | | reiserfs_fs.h | reiserfs_fs_sb.h | reiserfs_fs_i.h | | It is giving lots of errors | Any one has any clue Including kernel headers in userspace programs is unsupported. There are examples of userspace headers available in reiserfsprogs. - -Jeff - -- Jeff Mahoney SuSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBSJKFLPWxlyuTD7IRAv6oAJ0Q16D+cpxH2FHXJnA6EMWFsOvmyACfUE2q XZapVivGKe7AtKpjoao9omQ= =3pst -END PGP SIGNATURE-
Re: Reiser4 support on parted program ...
Yury Umanets wrote: Hans Reiser wrote: Dr. Giovanni A. Orlando wrote: As soon the installer works fine supporting Reiser4, including parted support it, I will comment in this mailing list, and offer for free donwload. Reiser4 resizer is not ready for prime time, and like pseudos, should not have been enabled before it was tested. We are going to send in a patch to turn it off until it is debugged. hello Hans, I suspect, that Dr. Giovanni A. Orlando meant offline resizer which should be in utils. Not online resizer-repacker... Actually, we want that reiser4 is supported inside parted program. Nothing else. I don't think this support will enable any other support like reiser4-resize. Thanks, Giovanni -- -- -- Check FT Websites ... http://www.futuretg.com - ftp://ftp.futuretg.com http://www.FTLinuxCourse.com http://www.FTLinuxCourse.com/Certification http://www.rpmparadaise.org http://GNULinuxUtilities.com http://www.YourPersonalOperatingSystem.com --
Re: Reiser4 support on parted program ...
Hans Reiser wrote: Dr. Giovanni A. Orlando wrote: As soon the installer works fine supporting Reiser4, including parted support it, I will comment in this mailing list, and offer for free donwload. Reiser4 resizer is not ready for prime time, and like pseudos, should not have been enabled before it was tested. We are going to send in a patch to turn it off until it is debugged. hello Hans, I suspect, that Dr. Giovanni A. Orlando meant offline resizer which should be in utils. Not online resizer-repacker... -- umka
Re: The argument for fs assistance in handling archives
Hey, you know how device nodes have a bit set, indicating that they're device nodes and not regular files? Can a set of such properties be defined for reiser4 metadata properties? Like a "metadata" bit so you can distinguish (if you wish) between regular files and metadata objects, and in addition an "archivable metadata" bit which indicates that the given piece of metadata is not automatically generated and should be archived during backup (some manually-generated metadata which does not need to be backed up will not have this bit set -- perhaps add another flag indicating that it's not automatic but unnecessary to archive).
Re: silent semantic changes with reiser4
I'm probably not the first to suggest this idea, and it's probably not a very good idea, but here's my idea anyhow: You have a file "/usr/bin/emacs" with a metadata property in the overlaid namespace "/usr/bin/emacs/[[..]metas/]icon" According to some, this could cause some confusion. Howabout instead: You have a file "/usr/bin/emacs" with a metadata property in a slightly separated namespace "/metas/usr/bin/emacs/icon" This has the advantage of still having the metadata in the filesystem namespace but without the confusion of having files-as-directories, ambiguity of filename, backup issues, etc. This is the reverse of having the namespaces overlaid with a "/nometas" view which is separate. Furthermore, you can split things further like this: You have a file "/usr/bin/emacs" with an automatically-generated metadata property that you don't want to back up in "/autometas/usr/bin/emacs/modification_date" and a manually generated metadata property that you MAY want to backup in "/staticmetas/usr/bin/emacs/icon". This is inelegant, I know. But if we do this, we can add the extra features of reiser4 without confusing existing apps or having to modify them to support the new functionality. Furthermore, you can easily hide the extra features by not mounting the meta top-level directories (assuming they're mounted like separate filesystems, rather than just magically appearing there, which is okay too).
Re: EACCESS vs ENOENT for nonexistent files-within-files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nikita Danilov wrote: | > attributes? Even if the file is world readable? Does this really make sense? | | To make things clear: I have described in my message how things actually | do work in reiser4, so I don't see the point of your questions. If you | think reiser4 semantics is wrong (I am not happy with it too, by the | way), propose to Namesys something better. I would suggest to allow lookups when the user can read the file. The x bit should remain for exec on file objects, because console would be pain when every file must have a exec bits to access meta data. When the user can read a file, i don't think that the meta data can be security risk, he has already access to the file. And therefor not write access to file/metas without +w. No, its not perfect, but i think more unix like than +x for lookups on files. regards ~ Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBSGqZy/mkIQp7AD0RAotiAKCTmffDuqsYj2KGkRtaE+fitU2e/QCfXS5t qZHo5nFd0m1wJFw7MNhDTX8= =Ejyo -END PGP SIGNATURE-
