On Mon, 12 Sep 2005 00:49:54 +0200, evilninja said:
[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
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
On Sat, 10 Sep 2005 17:36:49 +0200, evilninja said:
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?
Hello
michael chang wrote:
On 9/5/05, Gabor HALASZ [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]:~# touch
/home/ftpd/pub/debian/pool/main/x/xorg-x11/.in.xserver-xorg_6.8.2.dfsg.1-6_i386.deb
touch: cannot touch
`/home/ftpd/pub/debian/pool/main/x/xorg-x11/.in.xserver-xorg_6.8.2.dfsg.1-6_i386.deb':
Gabor HALASZ writes:
Hi!
I got the next message:
Sep 5 17:48:32 sk8n kernel: ReiserFS: dm-10: warning:
reiserfs_add_entry: Congratulations! we have got hash function screwed up
reiserfs v3 uses a hash of the file name as a part of a tree key to
store directory entry for that name
Hi!
I got the next message:
Sep 5 17:48:32 sk8n kernel: ReiserFS: dm-10: warning:
reiserfs_add_entry: Congratulations! we have got hash function screwed up
Caused by:
17:47:43 Getting file
'main/x/xorg-x11/xserver-xorg-dbg_6.8.2.dfsg.1-6_i386.deb' size = 21256772
17:48:32 Transfer rate
On 9/5/05, Gabor HALASZ [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]:~# touch
/home/ftpd/pub/debian/pool/main/x/xorg-x11/.in.xserver-xorg_6.8.2.dfsg.1-6_i386.deb
touch: cannot touch
`/home/ftpd/pub/debian/pool/main/x/xorg-x11/.in.xserver-xorg_6.8.2.dfsg.1-6_i386.deb':
Device or resource busy
Hi!
Gabor HALASZ wrote:
[EMAIL PROTECTED]:~# touch
/home/ftpd/pub/debian/pool/main/x/xorg-x11/.in.xserver-xorg_6.8.2.dfsg.1-6_i386.deb
touch: cannot touch
`/home/ftpd/pub/debian/pool/main/x/xorg-x11/.in.xserver-xorg_6.8.2.dfsg.1-6_i386.deb':
Device or resource busy
Errors like these I've
Hans Reiser wrote:
Grzegorz Jakiewicz wrote:
On Thu, 30 Dec 2004 08:40:51 -0800, Hans Reiser [EMAIL PROTECTED]
wrote:
Fixing hash collisions in V3 to do them the way V4 does them would
create more bugs and user disruption than the current bug we have all
lived with for 5 years until now. If
All I know is that xxtea is fixed tea algo. If that fixes weakness in
crypto algo, than so it should make hashing better.
No doubt there is no ideal hash algo, but if base algo has weaknes,
using fixed one only can be better, Right ?
--
GJ
Grzegorz Jakiewicz wrote:
On Thu, 30 Dec 2004 08:40:51 -0800, Hans Reiser [EMAIL PROTECTED] wrote:
Fixing hash collisions in V3 to do them the way V4 does them would
create more bugs and user disruption than the current bug we have all
lived with for 5 years until now. If someone thinks it is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
| Grzegorz Jakiewicz wrote:
|
| On Thu, 30 Dec 2004 08:40:51 -0800, Hans Reiser [EMAIL PROTECTED]
| wrote:
|
|
| Fixing hash collisions in V3 to do them the way V4 does them would
| create more bugs and user disruption than the
On Thu, 30 Dec 2004 08:40:51 -0800, Hans Reiser [EMAIL PROTECTED] wrote:
Fixing hash collisions in V3 to do them the way V4 does them would
create more bugs and user disruption than the current bug we have all
lived with for 5 years until now. If someone thinks it is a small
change to fix it,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
[...]
| I'm not sure I understand that. Is the idea of that to build up a write
| buffer which insists on flushing bytes off the front as they are added
| onto the back, without flushing huge chunks at once?
|
|
| Yes.
|
|
| Would
David Masover wrote:
Hans Reiser wrote:
| David Masover wrote:
|
| Hans Reiser wrote:
| | Chris Dukes wrote:
| |
| |
| |
| | All filesystems will fail or suffer degraded performance under
| | certain conditions, you need to determine what conditions are
| acceptable
| | for your data.
| |
| |
| |
Chris Dukes wrote:
All filesystems will fail or suffer degraded performance under
certain conditions, you need to determine what conditions are acceptable
for your data.
and each generation of software reduces the extent of such conditions.
Reiser4 fixes this problem cleanly.
On Thu, Jan 06, 2005 at 09:55:20PM +0300, Edward Shishkin [EMAIL PROTECTED]
wrote:
On Thu, Jan 06, 2005 at 03:45:06PM +0300, Alex Zarochentsev
[EMAIL PROTECTED] wrote:
Tea hash is designed to be more resistant.
Actually this can not be more resistant as it use the same 32-bit
On Fri, Jan 07, 2005 at 09:22:02AM -0800, Hans Reiser wrote:
Chris Dukes wrote:
All filesystems will fail or suffer degraded performance under
certain conditions, you need to determine what conditions are acceptable
for your data.
and each generation of software reduces the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
| Chris Dukes wrote:
|
|
|
| All filesystems will fail or suffer degraded performance under
| certain conditions, you need to determine what conditions are acceptable
| for your data.
|
|
|
| and each generation of software reduces
David Masover wrote:
Hans Reiser wrote:
| Chris Dukes wrote:
|
|
|
| All filesystems will fail or suffer degraded performance under
| certain conditions, you need to determine what conditions are
acceptable
| for your data.
|
|
|
| and each generation of software reduces the extent of such
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
| David Masover wrote:
|
| Hans Reiser wrote:
| | Chris Dukes wrote:
| |
| |
| |
| | All filesystems will fail or suffer degraded performance under
| | certain conditions, you need to determine what conditions are
| acceptable
| |
/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
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
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
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
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
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
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
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
On Thu, 30 Dec 2004, Hans Reiser wrote:
A working undelete can either hog disk space or die the moment some
large write comes in. And if you're at that point, make it a versioning
file system
Well, yes, it should be one.
darpa is paying for views, add in a little versioning and.
Hans Reiser [EMAIL PROTECTED] writes:
Again, this is a lame excuse for a bug. First you declare some features on
your filesystem, later, when it turns out that it isn't being delivered,
you act as if this were a known condition.
Well this is true, you are right. Reiser4 is the fix though.
No,
: Congratulations! we have got hash function screwed up
Hans Reiser [EMAIL PROTECTED] writes:
Again, this is a lame excuse for a bug. First you declare some
features on your filesystem, later, when it turns out that it isn't
being delivered, you act as if this were a known condition.
Well this is true
Yiannis Mavroukakis [EMAIL PROTECTED] writes:
Your proven reasoning sounds a bit strange to me..Microsoft (aka
major distributor at least in my books) had her filesystems in the
field for ages, does this prove any of them good (or bad for that
matter)?
My reasoning mentioned a /required/,
--
and then at Thu, 30 Dec 2004 13:40:53 +0100, it was written ...
...
Anyone is free to choose the file system, and as the simple
demonstration code posted earlier shows a serious flaw in reiserfs,
Hans's response was boldfaced, I ditched reiserfs3. End of story.
Your policy and
My reasoning mentioned a /required/, but not a /sufficient/ criterion.
In other words: not before it is proven in the field will I consider it
for production use.
Remember the Linux 2.2 reiserfs 3.5 NFS woes?
Remember the early XFS-NFS woes?
These are all reasons to avoid a shiny new file system
Yiannis Mavroukakis [EMAIL PROTECTED] writes:
I agree, but you're generalising, this is not xfs and reiser4 is not 3.5
;)
If you don't try out the shiny new filesystem yourself, how can you
possibly dismiss it based on the past failures
of other filesystems?
I doubt new software is
Cal [EMAIL PROTECTED] writes:
--
and then at Thu, 30 Dec 2004 13:40:53 +0100, it was written ...
...
Anyone is free to choose the file system, and as the simple
demonstration code posted earlier shows a serious flaw in reiserfs,
Hans's response was boldfaced, I ditched
On Thu, 30 Dec 2004, Hans Reiser wrote:
Fixing hash collisions in V3 to do them the way V4 does them would
create more bugs and user disruption than the current bug we have all
lived with for 5 years until now. If someone thinks it is a small
change to fix it, send me a patch. Better by
On Wed, Dec 29, 2004 at 06:05:59PM -0800, Hans Reiser [EMAIL PROTECTED] wrote:
Again, this is a lame excuse for a bug. First you declare some features on
your filesystem, later, when it turns out that it isn't being delivered,
you act as if this were a known condition.
Well this is
Matthias Andree [EMAIL PROTECTED] writes:
All private machines I deal with are reiserfs-free as of a few hours
ago.
What do you use instead?
I really don't like that there is no undelete feature in reiserfs -
it's not planned for reiserfs-4 either. I see desperate users all the
time trying to
On Thu, Dec 30, 2004 at 11:52:58AM -, Yiannis Mavroukakis [EMAIL
PROTECTED] wrote:
Your proven reasoning sounds a bit strange to me..Microsoft (aka major
distributor at least in my books) had her filesystems in the field for
ages, does this prove any of them good (or bad for that matter)?
On Thursday 30 December 2004 18:07, Esben Stien wrote:
Matthias Andree [EMAIL PROTECTED] writes:
All private machines I deal with are reiserfs-free as of a few hours
ago.
What do you use instead?
I really don't like that there is no undelete feature in reiserfs -
it's not planned for
You state that proven is the same as good, but why you do so
escapes me. In general, you can easily prove that black == white (etc.)
by such illogical reasoning.
No I don't :) I merely say that proven does not equal good OR bad if a
distributor chooses to bundle the filesystem with a
Esben Stien wrote (ao):
I really don't like that there is no undelete feature in reiserfs -
it's not planned for reiserfs-4 either. I see desperate users all the
time trying to get back what they mistakenly removed.
If you 'see desperate users all the time' you might be amoung the wrong
people
Sander [EMAIL PROTECTED] writes:
If you 'see desperate users all the time' you might be amoung the
wrong people ;-)
;), on the lists and on user groups.
Maybe you can clue them in the wonderful world of making backups?
I always promote bacula, but you will always have those who don't do
the
Esben Stien wrote (ao):
Sander [EMAIL PROTECTED] writes:
Next time it is not their mistake, but instead a broken harddisk.
Undelete wont save them then.
We got pretty good tools to restore from a hd with bad blocks.
dd it, loop it, fsck it.
I'm sure a friend of mine disagrees with
Sander [EMAIL PROTECTED] writes:
Maybe you can clue them in the wonderful world of making backups?
This is not always the case, btw
This might be caused by a faulty application as well if the system is
not secure enough.
Tools to scan the partition and give a list of possible restores
should
We got pretty good tools to restore from a hd with bad blocks.
dd it, loop it, fsck it.
Heh, heh. That won't help you if a circuit board, spindle, read head or
other mechanism fails. Then you better hope the data wasn't *that*
valuable or you know good platter recovery shop.
Backups are
Esben Stien wrote (ao):
I really don't like that there is no undelete feature in reiserfs -
it's not planned for reiserfs-4 either. I see desperate users all the
time trying to get back what they mistakenly removed.
If you 'see desperate users all the time' you might be amoung the wrong
Burnes, James [EMAIL PROTECTED] writes:
dd it, loop it, fsck it.
That won't help you if a circuit board, spindle, read head or other
mechanism fails.
Sure, but that is not a simple case of bad blocks;)
Then you better hope the data wasn't *that* valuable or you know
good platter recovery
Sander [EMAIL PROTECTED] writes:
dd it, loop it, fsck it.
I'm sure a friend of mine disagrees with you after paying big bucks
to a Norway based disk recovery company after a disk crash and zero
backups. A Dutch recovery company couldn't recover the disk.
Probably IBAS;). What was the
On Thu, Dec 30, 2004 at 07:46:09PM +0100, Esben Stien wrote:
It would be too expensive to do all this backup'ing in userspace. When
a file gets deleted, a proper procedure to retrieve it would be to
umount the filesystem, scan it for the data which was removed and then
put it back in the
Esben Stien wrote (ao):
Sander [EMAIL PROTECTED] writes:
I'm sure a friend of mine disagrees with you after paying big bucks
to a Norway based disk recovery company after a disk crash and zero
backups. A Dutch recovery company couldn't recover the disk.
Probably IBAS;). What was the
On Thu, 30 Dec 2004, Burnes, James wrote:
(BTW: If Hans is a little tired of working on Reiser3 it's probably
because he is currently stressed out making last minute tweaks on
Reiser4 and managing his team.
Cut him some slack. Email conversations don't show a number of things
we take for
On Thu, 30 Dec 2004, Esben Stien wrote:
Sure, but your not factoring in murphys law here. A tool to undelete
would come many people in handy who even got proper backup solutions.
You're asking for a versioned file system. If reiserfs v4 doesn't offer
such properties, find something else that
Sander [EMAIL PROTECTED] writes:
I did recover data that way several times back when I didn't do backups.
The problem is though that one file does not occupy one spot on the
harddisk. It might be spread all over the place. While the data might
still be there (on an idle disk), you miss the
Esben Stien wrote:
I really don't like that there is no undelete feature in reiserfs -
it's not planned for reiserfs-4 either.
Blame Linus for that. I would put it in, but he thinks it belongs in
userspace. I may still put it in someday and just not tell him.;-)
I'll just let the users know
pcg( Marc)@goof(A.).(Lehmann )com wrote:
which also doesn't cope with millions of files
in a dir, as opposed to the original claims by it's developers).
The generation number thing just isn't as good as teaching the tree to
cope with duplicate keys. Kudos to Nikita on that one.
Burnes, James wrote:
We got pretty good tools to restore from a hd with bad blocks.
dd it, loop it, fsck it.
Heh, heh. That won't help you if a circuit board, spindle, read head or
other mechanism fails. Then you better hope the data wasn't *that*
valuable or you know good platter recovery
A flaw in the filesystem, in my opinion, is equivalent to the space
ship crashing and all crew members die.
No, it isn't..
A dying filesystem is a bad thing.. But it's just a filesystem..
On Thu, Dec 30, 2004 at 09:57:29PM +0100, Adrian Ulrich wrote:
A flaw in the filesystem, in my opinion, is equivalent to the space
ship crashing and all crew members die.
No, it isn't..
A dying filesystem is a bad thing.. But it's just a filesystem..
... that causes the space ship to
Quoting Stefan Traby [EMAIL PROTECTED]:
On Thu, Dec 30, 2004 at 09:57:29PM +0100, Adrian Ulrich wrote:
A flaw in the filesystem, in my opinion, is equivalent to the space
ship crashing and all crew members die.
No, it isn't..
A dying filesystem is a bad thing.. But it's just a
Hans Reiser [EMAIL PROTECTED] writes:
I may still put it in someday and just not tell him.;-)
I'll just let the users know about it and not him.;-)
Hehe, nice;)
--
Esben Stien is [EMAIL PROTECTED]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[EMAIL PROTECTED]
Spam [EMAIL PROTECTED] writes:
In any case. Undelete has been since ages on many platforms. It IS a
useful feature. Accidents CAN happen for many reasons and in some
cases you may need to recover data.
Besides, a deletion does not fully remove the data, but just unlinks
it. In
Spam [EMAIL PROTECTED] writes:
In any case. Undelete has been since ages on many platforms. It IS a
useful feature. Accidents CAN happen for many reasons and in some
cases you may need to recover data.
Besides, a deletion does not fully remove the data, but just unlinks
it. In
Hans Reiser wrote:
Esben Stien wrote:
I really don't like that there is no undelete feature in reiserfs -
it's not planned for reiserfs-4 either.
Blame Linus for that. I would put it in, but he thinks it belongs in
userspace. I may still put it in someday and just not tell him.;-)
I'll just
David Masover wrote:
Hans Reiser wrote:
Esben Stien wrote:
I really don't like that there is no undelete feature in reiserfs -
it's not planned for reiserfs-4 either.
Blame Linus for that. I would put it in, but he thinks it belongs in
userspace. I may still put it in someday and just not tell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
| David Masover wrote:
|
| Hans Reiser wrote:
|
| Esben Stien wrote:
|
|
| I really don't like that there is no undelete feature in reiserfs -
| it's not planned for reiserfs-4 either.
|
| Blame Linus for that. I would put it in,
On Tue, Dec 28, 2004 at 11:12:18PM +0100, Marc A. Lehmann wrote:
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?
I
On Wed, Dec 29, 2004 at 07:55:29PM +0100, Stefan Traby [EMAIL PROTECTED]
wrote:
On Tue, Dec 28, 2004 at 11:12:18PM +0100, Marc A. Lehmann wrote:
ReiserFS: hdg2: warning: reiserfs_add_entry: Congratulations! we have
got hash function screwed up
Sure sounds like a filesystem bug
Stefan Traby wrote:
Here a script that works independent of hash (feel free to forward it to
bugtraq - it's a showstopper bug):
It is not independent of hash, it is hardcoded to be hash specific. It
is not a showstopper bug --- almost nobody cared about it for the last 5
years. If you
On Wed, Dec 29, 2004 at 01:05:38PM -0800, Hans Reiser [EMAIL PROTECTED] wrote:
Stefan Traby wrote:
Here a script that works independent of hash (feel free to forward it to
bugtraq - it's a showstopper bug):
is not a showstopper bug
If it keeps debian from being usable on reiserfs
On Wednesday 29 December 2004 22:43, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann )
wrote:
On Wed, Dec 29, 2004 at 01:05:38PM -0800, Hans Reiser [EMAIL PROTECTED]
wrote:
Stefan Traby wrote:
Here a script that works independent of hash (feel free to forward it to
bugtraq - it's a showstopper
On Wed, Dec 29, 2004 at 10:46:46PM +0100, Christian Iversen [EMAIL PROTECTED]
wrote:
On Wed, Dec 29, 2004 at 01:05:38PM -0800, Hans Reiser [EMAIL PROTECTED]
wrote:
Stefan Traby wrote:
Here a script that works independent of hash (feel free to forward it to
bugtraq - it's a
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?
Deleteing the fonts and installing the package works, but the next
75 matches
Mail list logo
