reiser4progs: FTBFS (amd64/gcc-4.0): static declaration of 'oid40_plug' follows non-static declaration
hi all,
i've just received the following bug report for reiser4progs debian
package version 1.03-1.
is this a known problem? what about the proposed patch?
thanks
domenico
ps: happy new year :)
- Forwarded message from Andreas Jochens [EMAIL PROTECTED] -
Date: Mon, 03 Jan 2005 17:55:02 +0100
From: Andreas Jochens [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: Bug#288414: reiser4progs: FTBFS (amd64/gcc-4.0): static declaration of
'oid40_plug' follows non-static declaration
When building 'reiser4progs' on amd64 with gcc-4.0,
I get the following error:
x86_64-linux-gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include
-D_REENTRANT -D_FILE_OFFSET_BITS=no -DENABLE_SYMLINKS -DENABLE_SPECIAL
-DENABLE_R5_HASH -DENABLE_FNV1_HASH -DENABLE_RUPASOV_HASH -DENABLE_TEA_HASH
-DENABLE_DEG_HASH -DENABLE_LARGE_KEYS -DENABLE_SHORT_KEYS -DENABLE_DOT_O_FIBRE
-DENABLE_EXT_1_FIBRE -DENABLE_EXT_3_FIBRE -DENABLE_LEXIC_FIBRE -O3 -Wall -g -O2
-W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -MT
liboid40_static_la-oid40.lo -MD -MP -MF .deps/liboid40_static_la-oid40.Tpo -c
oid40.c -o liboid40_static_la-oid40.o
oid40.c:206: error: static declaration of 'oid40_plug' follows non-static
declaration
oid40.c:11: error: previous declaration of 'oid40_plug' was here
make[5]: *** [liboid40_static_la-oid40.lo] Error 1
make[5]: Leaving directory `/reiser4progs-1.0.3/plugin/oid/oid40'
With the attached patch 'reiser4progs' can be compiled
on amd64 using gcc-4.0.
Regards
Andreas Jochens
diff -urN ../tmp-orig/reiser4progs-1.0.3/plugin/key/key_large/key_large.c
./plugin/key/key_large/key_large.c
--- ../tmp-orig/reiser4progs-1.0.3/plugin/key/key_large/key_large.c
2004-10-19 23:02:47.0 +0200
+++ ./plugin/key/key_large/key_large.c 2005-01-03 17:13:29.425846752 +0100
@@ -6,7 +6,7 @@
#ifdef ENABLE_LARGE_KEYS
#include key_large.h
-extern reiser4_plug_t key_large_plug;
+static reiser4_plug_t key_large_plug;
/* Returns minimal key */
static reiser4_key_t *key_large_minimal(void) {
diff -urN ../tmp-orig/reiser4progs-1.0.3/plugin/key/key_short/key_short.c
./plugin/key/key_short/key_short.c
--- ../tmp-orig/reiser4progs-1.0.3/plugin/key/key_short/key_short.c
2004-10-19 23:02:27.0 +0200
+++ ./plugin/key/key_short/key_short.c 2005-01-03 17:13:12.0 +0100
@@ -6,7 +6,7 @@
#ifdef ENABLE_SHORT_KEYS
#include key_short.h
-extern reiser4_plug_t key_short_plug;
+static reiser4_plug_t key_short_plug;
/* Returns minimal key */
static reiser4_key_t *key_short_minimal(void) {
diff -urN ../tmp-orig/reiser4progs-1.0.3/plugin/oid/oid40/oid40.c
./plugin/oid/oid40/oid40.c
--- ../tmp-orig/reiser4progs-1.0.3/plugin/oid/oid40/oid40.c 2004-12-02
17:13:27.0 +0100
+++ ./plugin/oid/oid40/oid40.c 2005-01-03 17:09:38.0 +0100
@@ -8,7 +8,7 @@
#include oid40.h
#include oid40_repair.h
-extern reiser4_plug_t oid40_plug;
+static reiser4_plug_t oid40_plug;
static uint32_t oid40_get_state(generic_entity_t *entity) {
aal_assert(umka-2088, entity != NULL);
- End forwarded message -
-[ Domenico Andreoli, aka cavok
--[ http://people.debian.org/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega. E poi hai l'Adsl senza limiti
a meno di 1 euro al giorno.
Abbonati subito senza costi di attivazione su http://www.libero.it
finding the key in reiser4
hello, i want to know that given a filename in reiser4 say "/root/abc.txt" how do u find the key for this file. I am confused in the following two ways: 1)Does the complete string that is the "/root/abc.txt" is converted into the key and then we traverse the tree using the key to read the data. Where the information about converting the name into key is stored? Is there some particular data structure or a way to convert such name directly into key? 2)Is the "/" key is first found and then we go to the directory item of the "/" to get the key of "root" and get the key for "abc.txt" and then traverse thetree for abc.txt. For that the "/" directory address should be stored somewhere or it should have a fixed address like in ext2? Pallavi Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now
Re: Recursive modified-timestamp?
Alexander G. M. Smith wrote: Possibly. But I'd like to generalize it a bit. Percolated attributes are perhaps a better more general idea. We already have inherited attributes (such as security of children being inherited from the parent) so going in the other direction isn't all that big step, it just needs an application, like your modification detection system. The general form of inheritance should not be restricted to inheriting from parents. Parents should merely be a default if nothing is specified as what one inherits from. And when one inherits, one can write through to what one inherits from, at least by default. At least, such are my thoughts on the matter. Hans
reiser4 problems on amd64: things to try?
Hello all, Tomorrow morning I'll reinstall (and reformat to reiser3) a dual Opteron which has a troublesome reiser4 fs. Should I run some tests, or retrieve some debug info from the reiser4 fs before I reformat? -- Humilis IT Services and Solutions http://www.humilis.net
Re: --rebuild-tree always finds errors --check is ok
Hello On Sun, 2005-01-02 at 00:55, hanasaki wrote: Running reiser3 on kernel 2.6.10 and 2.6.9 with Debian sarge and unstable. the --rebuild-tree always finds errors and corrects them. even when run more than once consecutively without mounting the partition in between. Please provide reiserfsck --rebuild-tree output. What is version of your reiserfsck? (reiserfsck -V) --check says all is good.
Re: reiser4 problems on amd64: things to try?
Hello On Mon, 2005-01-03 at 20:37, Sander wrote: Hello all, Tomorrow morning I'll reinstall (and reformat to reiser3) a dual Opteron which has a troublesome reiser4 fs. Should I run some tests, or retrieve some debug info from the reiser4 fs before I reformat? Please describe the problem you had with reiser4. Sorry, if you did that already. Then please do that one more time.
Re: reiser4 problems on amd64: things to try?
Hi, For some reason mails to the mailinglist don't make it. Also not to the archives, but I got no error back yet. And www.namesys.com was unreachable this morning (GMT+1). Vladimir Saveliev wrote (ao): On Mon, 2005-01-03 at 20:37, Sander wrote: Tomorrow morning I'll reinstall (and reformat to reiser3) a dual Opteron which has a troublesome reiser4 fs. Should I run some tests, or retrieve some debug info from the reiser4 fs before I reformat? Please describe the problem you had with reiser4. This was on kernel 2.6.10-rc3-mm1. bonnie++ went just fine with reiser4 on top of disk, raid0, raid1, raid5 and raid10. apt-get (Debian) on reiser4 raid10 gave segfaults so I let that run om tmpfs. I believe useradd also gave segfaults an crashed the system. Not sure though. I've reformatted the system already to reiser3, but I might be able to do some tests on reiser4 on a loopback device? -- Humilis IT Services and Solutions http://www.humilis.net
Re: --rebuild-tree always finds errors --check is ok
Version of reiserfsk == == From debian sarge /sbin/reiserfsck -V reiserfsck 3.6.19 (2003 www.namesys.com) == also used the version in knoppix 3.7 with similar results the output of two consecutive runs of --rebuild-tree on the same unmounted partition are attached. Below is the diff diff data00-run1 data00-run0 14c14 172168 directory entries were hashed with r5 hash. --- 172167 directory entries were hashed with r5 hash. Vladimir Saveliev wrote: Hello On Sun, 2005-01-02 at 00:55, hanasaki wrote: Running reiser3 on kernel 2.6.10 and 2.6.9 with Debian sarge and unstable. the --rebuild-tree always finds errors and corrects them. even when run more than once consecutively without mounting the partition in between. Please provide reiserfsck --rebuild-tree output. What is version of your reiserfsck? (reiserfsck -V) --check says all is good. ### Pass 0 ### block 254411: The number of items (21) is incorrect, should be (1) - corrected block 254411: The free space (1) is incorrect, should be (2256) - corrected pass0: vpf-10110: block 254411, item (0): Unknown item type found [0 251658496 0x1001800 ??? (15)] - deleted block 1574493: The number of items (18) is incorrect, should be (0) - corrected block 1574493: The free space (1184) is incorrect, should be (4072) - corrected block 2206239: The number of items (1) is incorrect, should be (0) - corrected block 2206239: The free space (0) is incorrect, should be (4072) - corrected block 2844875: The number of items (2) is incorrect, should be (1) - corrected block 2844875: The free space (0) is incorrect, should be (4048) - corrected pass0: vpf-10110: block 2844875, item (0): Unknown item type found [16777472 16780544 0x200 ??? (15)] - deleted block 3326501: The number of items (1) is incorrect, should be (0) - corrected block 3326501: The free space (0) is incorrect, should be (4072) - corrected 172167 directory entries were hashed with r5 hash. ### Pass 1 ### ### Pass 2 ### ### Pass 3 # ### Pass 3a (lost+found pass) # ### Pass 0 ### block 254411: The number of items (21) is incorrect, should be (1) - corrected block 254411: The free space (1) is incorrect, should be (2256) - corrected pass0: vpf-10110: block 254411, item (0): Unknown item type found [0 251658496 0x1001800 ??? (15)] - deleted block 1574493: The number of items (18) is incorrect, should be (0) - corrected block 1574493: The free space (1184) is incorrect, should be (4072) - corrected block 2206239: The number of items (1) is incorrect, should be (0) - corrected block 2206239: The free space (0) is incorrect, should be (4072) - corrected block 2844875: The number of items (2) is incorrect, should be (1) - corrected block 2844875: The free space (0) is incorrect, should be (4048) - corrected pass0: vpf-10110: block 2844875, item (0): Unknown item type found [16777472 16780544 0x200 ??? (15)] - deleted block 3326501: The number of items (1) is incorrect, should be (0) - corrected block 3326501: The free space (0) is incorrect, should be (4072) - corrected 172168 directory entries were hashed with r5 hash. ### Pass 1 ### ### Pass 2 ### ### Pass 3 # ### Pass 3a (lost+found pass) #
Re: Status of quota support for reiserfs on 2.6.x kernels
Sorry for a bit late reply but I was on a holidays.
On Wed, Dec 15, 2004 at 02:38:06PM +0100, Jan Kara wrote:
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).
It tried the latter on another server and the filesystem was accessible
at all time but other problems occured (maybe not quota-related) that made
my co-admins downgrade to 2.6.9:
1. suddenly, after running the patched kernel for days,
su, sudo and authentication through courier webmailer was not possible,
ssh-root-login went fine. After reboot problem was gone but pam_rootok.so
was missing (file system curruption?)
Are there any error messages in the log? If that was filesystem
corruption there should be some Otherwise it's hard to guess what
was going on.
2. after a few hours stress-testing the quota-partition:
kernel crash: code ff 21 e2 8b 0a ...
... 76 60 e0 ff 6a 00
kernel BUG at lib/kernel_lock:120!
invalid operand:
This does not look nice. Do you have all the error message? From this
part it's hard to guess what has happened.
Do you think they are quota-related or related to you quota-fixall patch?
They might be - you can try to stress-test the filesystem without
quotas enabled and see if some error occurs.
Is your fix appliable for vanilla 2.6.10 or is it already integrated
or is there a newer patch?
The patch I sent you should be applicable to 2.6.10 kernel. There's also one
other bugfix to my quota-fixall patch which I attached (but you don't seem to
actually hit that problem).
Honza
When CONFIG_QUOTA is defined reiserfs's finish_unfinished sets and clears
MS_ACTIVE bit in s_flags field of super block. If that bit was set already
it should not be set.
fs/reiserfs/super.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff -puN fs/reiserfs/super.c~reiserfs-do-not-clear-MS_ACTIVE
fs/reiserfs/super.c
--- linux-2.6.10-rc3-mm1/fs/reiserfs/super.c~reiserfs-do-not-clear-MS_ACTIVE
2004-12-23 18:22:06.568755520 +0300
+++ linux-2.6.10-rc3-mm1-vs/fs/reiserfs/super.c 2004-12-23 18:22:06.576756006
+0300
@@ -158,6 +158,7 @@ static int finish_unfinished (struct sup
int truncate;
#ifdef CONFIG_QUOTA
int i;
+int ms_active_set;
#endif
@@ -168,7 +169,12 @@ static int finish_unfinished (struct sup
#ifdef CONFIG_QUOTA
/* Needed for iput() to work correctly and not trash data */
-s-s_flags |= MS_ACTIVE;
+if (s-s_flags MS_ACTIVE) {
+ ms_active_set = 0;
+} else {
+ ms_active_set = 1;
+ s-s_flags |= MS_ACTIVE;
+}
/* Turn on quotas so that they are updated correctly */
for (i = 0; i MAXQUOTAS; i++) {
if (REISERFS_SB(s)-s_qf_names[i]) {
@@ -276,8 +282,9 @@ static int finish_unfinished (struct sup
if (sb_dqopt(s)-files[i])
vfs_quota_off_mount(s, i);
}
-/* Restore the flag back */
-s-s_flags = ~MS_ACTIVE;
+if (ms_active_set)
+ /* Restore the flag back */
+ s-s_flags = ~MS_ACTIVE;
#endif
pathrelse (path);
if (done)
_
Re: --rebuild-tree always finds errors --check is ok
Hello On Tue, 2005-01-04 at 20:25, hanasaki wrote: Version of reiserfsk == == From debian sarge /sbin/reiserfsck -V reiserfsck 3.6.19 (2003 www.namesys.com) == also used the version in knoppix 3.7 with similar results the output of two consecutive runs of --rebuild-tree on the same unmounted partition are attached. Below is the diff diff data00-run1 data00-run0 14c14 172168 directory entries were hashed with r5 hash. --- 172167 directory entries were hashed with r5 hash. Vladimir Saveliev wrote: Hello On Sun, 2005-01-02 at 00:55, hanasaki wrote: Running reiser3 on kernel 2.6.10 and 2.6.9 with Debian sarge and unstable. the --rebuild-tree always finds errors and corrects them. even when run more than once consecutively without mounting the partition in between. Please provide reiserfsck --rebuild-tree output. What is version of your reiserfsck? (reiserfsck -V) --check says all is good. __ ### Pass 0 ### block 254411: The number of items (21) is incorrect, should be (1) - corrected block 254411: The free space (1) is incorrect, should be (2256) - corrected pass0: vpf-10110: block 254411, item (0): Unknown item type found [0 251658496 0x1001800 ??? (15)] - deleted block 1574493: The number of items (18) is incorrect, should be (0) - corrected block 1574493: The free space (1184) is incorrect, should be (4072) - corrected block 2206239: The number of items (1) is incorrect, should be (0) - corrected block 2206239: The free space (0) is incorrect, should be (4072) - corrected block 2844875: The number of items (2) is incorrect, should be (1) - corrected block 2844875: The free space (0) is incorrect, should be (4048) - corrected pass0: vpf-10110: block 2844875, item (0): Unknown item type found [16777472 16780544 0x200 ??? (15)] - deleted block 3326501: The number of items (1) is incorrect, should be (0) - corrected block 3326501: The free space (0) is incorrect, should be (4072) - corrected 172167 directory entries were hashed with r5 hash. ### Pass 1 ### ### Pass 2 ### ### Pass 3 # ### Pass 3a (lost+found pass) # __ ### Pass 0 ### block 254411: The number of items (21) is incorrect, should be (1) - corrected block 254411: The free space (1) is incorrect, should be (2256) - corrected pass0: vpf-10110: block 254411, item (0): Unknown item type found [0 251658496 0x1001800 ??? (15)] - deleted block 1574493: The number of items (18) is incorrect, should be (0) - corrected block 1574493: The free space (1184) is incorrect, should be (4072) - corrected block 2206239: The number of items (1) is incorrect, should be (0) - corrected block 2206239: The free space (0) is incorrect, should be (4072) - corrected block 2844875: The number of items (2) is incorrect, should be (1) - corrected block 2844875: The free space (0) is incorrect, should be (4048) - corrected pass0: vpf-10110: block 2844875, item (0): Unknown item type found [16777472 16780544 0x200 ??? (15)] - deleted block 3326501: The number of items (1) is incorrect, should be (0) - corrected block 3326501: The free space (0) is incorrect, should be (4072) - corrected 172168 directory entries were hashed with r5 hash. ### Pass 1 ### ### Pass 2 ### ### Pass 3 # ### Pass 3a (lost+found pass) # Can you do: debugreiserfs -p that-device | gzip -c fs.gz and make fs.gz downloadable. That would allow us to fix reiserfsck bug faster.
Re: Congratulations! we have got hash function screwed up
Hello, On Tue, Dec 28, 2004 at 11:12:18PM +0100, Marc A. Lehmann wrote: Hi! When trying to upgrade or reinstall the xfonts-75dpi, xfonts-75dpi-transcoded or 100dpi transcoded debian packages on my 2.6.10-rc3 amd64 reiserfsv3 host, I get the following errors: dpkg: error processing /var/cache/apt/archives/xfonts-75dpi_4.3.0.dfsg.1-10_all.deb (--unpack): unable to make backup link of `./usr/X11R6/lib/X11/fonts/75dpi/lutBS19-ISO8859-1.pcf.gz' before installing new version: Device or resource busy dpkg-deb: subprocess paste killed by signal (Broken pipe) Preparing to replace xfonts-75dpi-transcoded 4.3.0.dfsg.1-10 (using .../xfonts-75dpi-transcoded_4.3.0.dfsg.1-10_all.deb) ... dpkg: error processing /var/cache/apt/archives/xfonts-75dpi-transcoded_4.3.0.dfsg.1-10_all.deb (--unpack): unable to make backup link of `./usr/X11R6/lib/X11/fonts/75dpi/lutBS19-ISO8859-10.pcf.gz' before installing new version: Device or resource busy dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/xfonts-75dpi_4.3.0.dfsg.1-10_all.deb /var/cache/apt/archives/xfonts-75dpi-transcoded_4.3.0.dfsg.1-10_all.deb And at the same time, I get this in my kernel log: ReiserFS: hdg2: warning: reiserfs_add_entry: Congratulations! we have got hash function screwed up Sure sounds like a filesystem bug to me. Is this 2.6.10-rc3-specific or a generic bug in handling hash collisions? Tea hash is designed to be more resistant. there is a generic problem with overloading of the generation counter, but tea hash should mix file names better and have less chances to 'screw the hash function up'. Does the debian install all X font files into one dir? May be you have your own font files installed in the same dir? I suggest to split the dir into several ones. Deleteing the fonts and installing the package works, but the next upgrade makes the error appear again. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE -- Alex.
Re: Congratulations! we have got hash function screwed up
On Thu, Jan 06, 2005 at 03:45:06PM +0300, Alex Zarochentsev [EMAIL PROTECTED] wrote: generic bug in handling hash collisions? Tea hash is designed to be more resistant. As the example posted shows, tea doesn't look better, it generates nicely-looking collisions, too. Does the debian install all X font files into one dir? No, but xfree nowadays comes with a lot of fonts because it stupidly makes a copy of about each and every font in each and every encoding, leading to many font files in the bitmapped category (75dpi and 100dpi). May be you have your own font files installed in the same dir? I also have some other debian packages that install their fonts there, but it should be less than 10 extra files. I suggest to split the dir into several ones. I'd suggest getting rid of reiserfs on anything important. I can't have it when my filesystem randomly returns errors when it should be working. I wonder wether this hasn't any security relevance, as it allows attackers easily to create filename holes in the filesystem that even root cannot override. Thanks for the suggestion, though! However, the workaround I currently use (delete the dir, reinstall) works better, as it doesn't destroy debian's idea of the filesystem layout. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Re: Congratulations! we have got hash function screwed up
pcg( Marc)@goof(A.).(Lehmann )com wrote: On Thu, Jan 06, 2005 at 03:45:06PM +0300, Alex Zarochentsev [EMAIL PROTECTED] wrote: generic bug in handling hash collisions? Tea hash is designed to be more resistant. As the example posted shows, tea doesn't look better, it generates nicely-looking collisions, too. You mean, in practice you hit them, or with an artificially generated set of filenames intended to cause collisions you get those collisions?
Re: Congratulations! we have got hash function screwed up
generic bug in handling hash collisions? Tea hash is designed to be more resistant. As the example posted shows, tea doesn't look better, it generates nicely-looking collisions, too. You mean, in practice you hit them, or with an artificially generated set of filenames intended to cause collisions you get those collisions? Excuse me, but do you mean that there are undocumented limits on what files can be named to, and how many files with similar or random names in a ReiferFS volume? This sounds bad...
Re: Congratulations! we have got hash function screwed up
On Thu, Jan 06, 2005 at 05:13:23PM +0100, Spam wrote: generic bug in handling hash collisions? Tea hash is designed to be more resistant. As the example posted shows, tea doesn't look better, it generates nicely-looking collisions, too. You mean, in practice you hit them, or with an artificially generated set of filenames intended to cause collisions you get those collisions? Excuse me, but do you mean that there are undocumented limits on what files can be named to, and how many files with similar or random names in a ReiferFS volume? No, I'd say it's pretty well documented that reiserfs fails under certain hash collision conditions instead of continueing to work (albeit more slowly). The nature of the hash collisions must be pretty obvious if a shell script can be written to demonstrate the problem. This sounds bad... It's a risk assessment. What are the odds of your normal data sets hitting the bug or of someone with malicious intent introducing a demonstration program vs the performance hit of a filesystem without the problem. All filesystems will fail or suffer degraded performance under certain conditions, you need to determine what conditions are acceptable for your data. -- Chris Dukes Warning: Do not use the reflow toaster oven to prepare foods after it has been used for solder paste reflow. http://www.stencilsunlimited.com/stencil_article_page5.htm
Re: Congratulations! we have got hash function screwed up
On Thu, Jan 06, 2005 at 05:13:23PM +0100, Spam wrote: generic bug in handling hash collisions? Tea hash is designed to be more resistant. As the example posted shows, tea doesn't look better, it generates nicely-looking collisions, too. You mean, in practice you hit them, or with an artificially generated set of filenames intended to cause collisions you get those collisions? Excuse me, but do you mean that there are undocumented limits on what files can be named to, and how many files with similar or random names in a ReiferFS volume? No, I'd say it's pretty well documented that reiserfs fails under certain hash collision conditions instead of continueing to work (albeit more slowly). The nature of the hash collisions must be pretty obvious if a shell script can be written to demonstrate the problem. This sounds bad... It's a risk assessment. What are the odds of your normal data sets hitting the bug or of someone with malicious intent introducing a demonstration program vs the performance hit of a filesystem without the problem. How can I assess the risk, if I do not know how to produce the bugs? You say certain conditions. But from what I read earlier in the thread, a directory with a fonts in them.? All filesystems will fail or suffer degraded performance under certain conditions, you need to determine what conditions are acceptable for your data. Slow can be acceptable. But failing? No, a filesystem should not fail. --
Re: Congratulations! we have got hash function screwed up
On Thu, Jan 06, 2005 at 05:29:39PM +0100, Spam wrote: It's a risk assessment. What are the odds of your normal data sets hitting the bug or of someone with malicious intent introducing a demonstration program vs the performance hit of a filesystem without the problem. How can I assess the risk, if I do not know how to produce the bugs? You say certain conditions. But from what I read earlier in the thread, a directory with a fonts in them.? Since the concepts of simulators, hash function analysis, and dataset modelling seem to escape you, perhaps you need to go for the black and white Is any risk acceptable, given anecdotal data of one unexpected failing condition and one script that can regularly create the failing condition. All filesystems will fail or suffer degraded performance under certain conditions, you need to determine what conditions are acceptable for your data. Slow can be acceptable. But failing? No, a filesystem should not fail. It should not fail 1) When media fails 2) When transport hardware is not compliant with specs (permanently on write caching anyone?) 3) Media has a limited lifetime ... One thing I don't think I ever saw in this thread was 1) How old was the drive that saw the problem. 2) What was the drive lifetime used to calculate it's MTBF. -- Chris Dukes Warning: Do not use the reflow toaster oven to prepare foods after it has been used for solder paste reflow. http://www.stencilsunlimited.com/stencil_article_page5.htm
Re: Congratulations! we have got hash function screwed up
pcg( Marc)@goof(A.).(Lehmann )com wrote: On Thu, Jan 06, 2005 at 03:45:06PM +0300, Alex Zarochentsev [EMAIL PROTECTED] wrote: generic bug in handling hash collisions? Tea hash is designed to be more resistant. Actually this can not be more resistant as it use the same 32-bit output size. So to find a collision you just need to find hashes of 2^16 = 65536 random documents. As the example posted shows, tea doesn't look better, it generates nicely-looking collisions, too. I'd suggest getting rid of reiserfs on anything important. I can't have it when my filesystem randomly returns errors when it should be working. I wonder wether this hasn't any security relevance, as it allows attackers easily to create filename holes in the filesystem that even root cannot override. It should be a weighty reason to use strong hash function for creating entries because stable hash means bad performance and more occupied place in stat-data: I am not sure that even 160 bit will guarantee absence of collision for a long time.. Edward. Thanks for the suggestion, though! However, the workaround I currently use (delete the dir, reinstall) works better, as it doesn't destroy debian's idea of the filesystem layout.
What grandpa doesn't know reiserfs-list [part I]
Title: Support Response Joke of the day A dedicated Teamsters union worker was attending a convention in Las Vegas and, as you would expect, decided to check out the brothels nearby. When he got to the first one, he asked the Madam, "Is this a union house?" "No," she replied. "I'm sorry, it isn't." "Well, if I pay you 100.00, what cut do the girls get?" "The house gets 80.00 and the girls get 20.00." Mightily offended at such unfair dealings, the man stomped off down the street in search of a more equitable, hopefully unionized shop. His search continued until finally he reached a brothel where the Madam responded, "Why, yes, sir, this IS a Union House." The man asked, "And if I pay you 100.00, what cut do the girls get?" "The girls get 80.00 and the house gets 20.00." "That's more like it!" the union man said. So he handed the Madam 100.00, looked around the room and pointed to a stunningly attractive blonde. "I'd like her for the night." "Sorry, sir," said the Madam, gesturing towards an 85-year old woman in the corner, "Ethel here has seniority."
