Re: Where's the link to the Reiser 4 source code?

[evilninja]

Lares Moreau schrieb:

RElated...

Is there any particular reason there is not an anonCVS/SVN repository?
to make Code access easier, and not limited to the (pseudo)Official
packages?


if the website is correct, then Reiser3+4 is developed via BK:

http://www.namesys.com/code.html

Christian.
--
BOFH excuse #197:

I'm sorry a pentium won't do, you need an SGI to connect with us.

Re: reiserfs in cryptoloop file is corrupt: all data lost?

[evilninja]

Detlef Grittner schrieb:
An appropriate fstab entry, so a user is allowed to mount the device 
looks like this:
/home/userX/data /home/userX/crypto  reiserfs   
user,noauto,loop=/dev/loop0,encryption=twofish256,phash=sha512,itercountk=100 


so, you're using a file-backed cryptoloop setup? these setups are often 
reported to deadlock. but this only as a side-note...


I have done a reiserfsck --check, which told me I should run reiserfsck 
--rebuild-sb and then a reiserfsck --rebuild-tree. The last one 
obviously failed and just told me that there is no reiserfs meta data.


you ran reiserfsck on what? on the losetup'ed /dev/loop0 i hope ;-)
please provide the output of the reiserfsck run. please make sure that 
you're running a current version of reiserfsprogs / current kernel.


I want to know, if it is worth a try, otherwise I won't spend time and 
money on it.


well, it's only $25 at http://www.namesys.com/support.html ;-)

Christian.
--
BOFH excuse #34:

(l)user error

Re: Reiserfsck can't fix FS

[evilninja]

Thomas Raschbacher schrieb:

how would I best copy the filesystem? DD ?


dd, if that does not work then try dd_rescue:

http://www.garloff.de/kurt/linux/ddrescue/

Christian.
--
BOFH excuse #34:

(l)user error

Re: Reiserfsck can't fix FS

[evilninja]

Thomas Raschbacher schrieb:


as you see it produced no errors at all so the HDD can be read fine. any
idea what could cause the problem?


looking once more on your logfiles:

> Pass 1 (will try to insert 16439 leaves):
> Looking for allocable blocks .. finished
> 0%20%40%60%80%. left 1982,
> 176 /sec
> The problem has occurred looks like a hardware problem (perhaps
> memory). Send us the bug report only if the second run dies at
> the same place with the same block number.
>
> build_the_tree: Nothing but leaves are expected. Block 10059767 -
> unknown

the block number is indeed the same on every (?) reiserfsck-run. so maybe 
you can put your disk into another machine and/or free your usb-disk from 
usb and use it via (S)ATA? (if possible, to rule out hw-problems).


and:

> I had to run reiserfsck on my usb hdd because there were some problems.

your reiserfs seems to be heavily damaged. can you tell us more about 
these "problems"?


thanks,
Christian.
--
BOFH excuse #76:

Unoptimized hard drive

benchmarks galore...

[evilninja]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

[cc'ing 4 mailing lists, please reply to *one* list only!]

hi,

every now and then i'm running some benchmarks on filesystems i really
use...here are the results:

http://nerdbynature.de/bench/prinz64/2.6.14-rc2-mm2/bonnie.html
http://nerdbynature.de/bench/prinz64/2.6.14-rc2-mm2/

may it be of some help

thanks,
Christian.

PS: reiser4 not included because of the recent compile error, i'll
probably add this one.
- --
BOFH excuse #197:

I'm sorry a pentium won't do, you need an SGI to connect with us.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDRwciC/PVm5+NVoYRAy8FAJ4/OAdv9skHmsC5Q0fjy0+qi7HuIgCfSMQs
1EcbBrnIh21MxajBvMtVw4g=
=aFUJ
-END PGP SIGNATURE-

Re: we have got hash function screwed up

[evilninja]

[EMAIL PROTECTED] schrieb:
> Yes, I know there's needs to support borked legacy filesystems that were 
> mkfs'ed
> before the problem was recognized.  That means fsck.reiserfs needs to know 
> about
> it - but mkfs.reiserfs??  Seen in the Fedora Core devel tree as of tonight:

yeah, this "feature" of mkfs.reiserfs could be removed, but since reiserfs
is in bugfixes-only-mode i don't see it happen.

i am really curious though, why the OP used rupasov hash at all. r5 is the
default algorithm for years now.

-- 
BOFH excuse #80:

That's a great computer you have there; have you considered how it would
work as a BSD machine?

Re: we have got hash function screwed up

[evilninja]

Gabor HALASZ schrieb:
> Sep  5 12:30:24 sk8n kernel: ReiserFS: dm-10: checking transaction log
> (dm-10)
> Sep  5 12:30:24 sk8n kernel: ReiserFS: dm-10: Using rupasov hash to sort
> names

why did you choose the rupasov hash?
http://www.namesys.com/mount-options.html knows:

rupasov: [...] Never use it, as it has high probability of hash
 collisions.

-- 
BOFH excuse #234:

Someone is broadcasting pygmy packets and the router doesn't know how to
deal with them.

Re: changing label of disk

[evilninja]

Bedros Hanounik schrieb:
> 
> mkfs.reiserfs -l label will overwrite the old data; is there a way to edit 
> the old lable w/o reformating the disk, other than hexedit the disk?

reiserfstune -l LABEL

should do the job.

(and xfs_admin for XFS, jfs_tune for JFS ;)

-- 
BOFH excuse #219:

Recursivity.  Call back if it happens again.

Re: Wikipedia article

[evilninja]

Dr. Giovanni A. Orlando schrieb:
> 
> This table is interesting but have really no sense the "no inclusion" of
> a minimal comparision about performance.

double negation...if i understand you correctly, you want a benchmark
comparison of the compared filesystems? uh, you know how hard it is to
compare these things The Right Way and i think that's beyon the scope of
the article. the results would be edited back-and-forth, because everone
has probably different results at hand and the "discussion" tab would be
set on fire from the ongoing flamewars

Christian.

PS: http://nerdbynature.de/bench/prinz64/2.6.13-rc2-mm2/bonnie.html
-- 
BOFH excuse #219:

Recursivity.  Call back if it happens again.

Re: Wikipedia article

[evilninja]

evilninja schrieb:
> - Maximum filename length
> - Maximum pathname length (currently "No limit defined" <-- is this true?)

in the thread "REISERFS_MAX_NAME and ENAMETOOLONG" it is stated, that max.
filename length is not a kernel limit but a libc limit of 255 chars.
right? an in the same thread PATH_MAX is named to be the limit for "max
pathname lenght", which is currently 4096 bytes.

i just wonder why almost all other fs are listed with "255 bytes" for max
filename lenght and "No limit defined" for max. pathname lenght...

i shall update the wikipedia entry if no objections are filed...
Christian.
-- 
BOFH excuse #217:

The MGs ran out of gas.

Re: Wikipedia article

[evilninja]

Gregory Maxwell schrieb:
> Someone might want to update the information on reiser4 at:
> 
> http://en.wikipedia.org/wiki/Comparison_of_file_systems

yeah, i noticed this too some time ago. so, what's the

- Maximum filename length
- Allowable characters in directory entries (e.g. "Any byte except NUL"?)
- Maximum volume size (16TiB on ReiserFS v3)
- Maximum pathname length (currently "No limit defined" <-- is this true?)

for Reiser4?

thanks,
Christian.
-- 
BOFH excuse #94:

Internet outage

Re: Reiser4 oops with 2.6.13-rc6-mm2

[evilninja]

Ronald Moesbergen schrieb:
> Well, I just successfully reproduced this without the nvidia module
> loaded. The oops looks very similar:
[...]
>  kernel: Modules linked in: vmnet vmmon
>  kernel: CPU:1
>  kernel: EIP:0060:[lock_object+84/127]Tainted: P  VLI

well, the kernel is still tainted - by the vmware modules. but as Vladimir
pointed out, there seem to be vmware related issues in reiser4. so you
could wait for the fix or try to reproduce with an untainted kernel (maybe
it's a completly different problem which needs to be fixed).

Christian.
-- 
BOFH excuse #432:

Borg nanites have infested the server

Re: REISERFS: panic... Trying to log block (prints.c:362)

[evilninja]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

M schrieb:
> It dies within about 30 seconds of issuing the tar command and is
> repeatable. So the question is why is the filesytem corrupt?

hm, bad memory? bad cabling? running memtest86 overnight just to be sure
could help. and: can you reproduce the problem with an untainted kernel?

> problem? Would turning off preemntion help?

well, have you tried (to disable CONFIG_PREEMPT)?

- --
BOFH excuse #245:

The Borg tried to assimilate your system. Resistance is futile.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCryAvC/PVm5+NVoYRAhC9AKDXDBLXU0BOOuJacxHPY8lgK6krCACg+Yy2
i3Fwy0lFricZBF0o5xllTtE=
=O0V8
-END PGP SIGNATURE-

Re: Corrupt reiser3 fs

[evilninja]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Gear schrieb:
> The problem has occurred looks like a hardware problem (perhaps
> memory). Send us the bug report only if the second run dies at
> the same place with the same block number.

sodoes it? is it reproduceable on a 2nd run? also with a different
(maybe vanilla) kernel?

before trashing the fs, you could do

  debugreiserfs -p /dev/HDD | bzip2 -c > HDD-meta.bz2

then some reiserfs-guru could use it for debugging.

- --
BOFH excuse #316:

Elves on strike. (Why do they call EMAG Elf Magic)

- --
BOFH excuse #316:

Elves on strike. (Why do they call EMAG Elf Magic)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCrHJkC/PVm5+NVoYRAms/AKC3Nhrq8iRUxjU+PQzI9IXpGVtNOgCfcZ0F
gQBaoD9ga8lKfr1qgB24T7U=
=V18Z
-END PGP SIGNATURE-

Re: Reiser4 O_DIRECT

[evilninja]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:
> 
> Any suggestions for performance/latency benchmark suites, preferrably
> automated, are welcome, of course ;)

fwiw, i did some benchmarks, and will do with new hardware soon:

http://nerdbynature.de/bench/prinz/2.6.12-rc3-mm2/bonnie.html



- --
BOFH excuse #214:

Fluorescent lights are generating negative ions. If turning them off
doesn't work, take them out and put tin foil on the ends.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCliKNC/PVm5+NVoYRAn8fAKDW/zJTq5HGaAjr2G+1RTb++ogsSwCg18Tr
Lwy+LS0LpFUZWMOzMt9fXDk=
=QznS
-END PGP SIGNATURE-

Re: Reiserfs kernel config description outdated

[evilninja]

Christian Mayrhuber wrote:
> I think the sentence "Additional patches are needed
> for NFS and quotas, please see  for links."
> should be dropped in 2.6.

maybe the patch could go in?

-- 
BOFH excuse #182:

endothermal recalibration
--- linux-2.6/fs/Kconfig2004-11-10 14:15:25.0 +0100
+++ linux-2.6/fs/Kconfig.edited 2004-11-19 01:05:38.0 +0100
@@ -170,14 +170,13 @@
  architectural foundations.
 
  In general, ReiserFS is as fast as ext2, but is very efficient with
- large directories and small files.  Additional patches are needed
- for NFS and quotas, please see  for links.
+ large directories and small files.
 
  It is more easily extended to have features currently found in
  database and keyword search systems than block allocation based file
  systems are.  The next version will be so extended, and will support
- plugins consistent with our motto ``It takes more than a license to
- make source code open.''
+ plugins consistent with our motto "It takes more than a license to
+ make source code open."
 
  Read  to learn more about reiserfs.
 

Re: SUSE 9.1 with ReiserFS: / won't fsck, but is otherwise fine

[evilninja]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Worley wrote:
> I find the root partition an invaluable part of the system.  So, I'm not
> going to destroy it on purpose.  I'm not quite sure how to boot without
> a root partition ;)

you did backup at least /etc , didn't you? if so, then a quick reinstall
of your distro (and thus overwriting "/" ) should be not that painful.

> I'm really looking for a non-destructive way to test/repair whatever has
> happened. 

well, there's always http://www.namesys.com/support.html   ;)

Christian.
- --
BOFH excuse #71:

The file system is full of it
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBWgQDC/PVm5+NVoYRApvLAKCXAWCz3PrDzLehnrTBEUeIGtwFWACgkIdh
wr4EZlLE0y76Srjny9Bt8Qw=
=i5O+
-END PGP SIGNATURE-

Re: SUSE 9.1 with ReiserFS: / won't fsck, but is otherwise fine

[evilninja]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Worley wrote:
> On Mon, 2004-09-27 at 08:44, Vitaly Fertman wrote:
> 
>>># ./fsck/reiserfsck  /dev/system/lvol0
>>>reiserfsck 3.6.18 (2003 www.namesys.com)
>>>
>>>Failed to open the device '/dev/system/lvol0': No such device or address
>>
>>it seems 
>>  open ('/dev/system/lvol0', O_RDONLY);
>>returns "No such device or address". You can check it with strace.
>>
>>what if you run
>>  reiserfsck /dev/mapper/system-lvol0
> 
> 
> 
> The strace dies on the open:
> 
> ...
> open("/dev/mapper/system-lvol0", O_RDONLY|O_LARGEFILE) = -1 ENXIO (No such device or 
> address)
> ...
> 
> Not even dd can open it:
> 
> # dd if=/dev/mapper/system-lvol0 bs=1024 count=1024 | sum
> dd: opening `/dev/mapper/system-lvol0': No such device or address

ah, now this is funny. dd doesn't care about the filesystem and can't even
read the device. this does not seem like a (reiser-)fs issue, more like a
corrupted partition table / device (if the data on
/dev/mapper/system-lvol0 is not (!) important, you could play around with

  $ mkfs.{ext3|xfs|reiserfs} /dev/mapper/system-lvol0

and see what it gives. (probably won't work too)

good luck,
Christian.
- --
BOFH excuse #180:

ether leak
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBWI5oC/PVm5+NVoYRAhM1AJ9Vwr+oX8Z7SaiRqzK5TPDn2tnS3gCg7K3K
VFq2Eped9ceUjbCWyOi+/+k=
=qVnK
-END PGP SIGNATURE-

Re: EACCESS vs ENOENT for nonexistent files-within-files

[evilninja]

-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-