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?
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 file
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 don't
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 usab
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 show
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 -
pcg( Marc)@goof(A.).(Lehmann )com 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 true, you are right. Reiser4 is the fix though.
(
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 th
fs-list@namesys.com; Stefan Traby
Subject: Re: 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&
"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 /re
--
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 an
>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 syst
"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 ditche
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 far to fix bugs in V4,
which is pretty stable
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
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.
> >
> >
> Wel
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
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 m
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 plan
>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 distr
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
peop
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
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 disagr
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
shoul
> 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 th
"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 r
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
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 wa
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
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 t
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 ab
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 s
Alias rm to 'mv $@ trash/' (not sure about the $@ - my bash is rusty) and
have a cronjob that reaps files older than x. Or, try pdumpfs (i've been
using it for a long time).
--
Tom Vier <[EMAIL PROTECTED]>
DSA Key ID 0x15741ECE
> 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
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..
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.
> 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 unlink
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 le
Matthias Andree wrote:
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 unli
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 h
-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
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
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 proc
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 debi
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
nic
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 ge
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.
> 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 c
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
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 outp
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
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
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 fi
Grzegorz JaÅkiewicz 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 i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
| Grzegorz JaÅkiewicz 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
Hans Reiser wrote:
Grzegorz JaÅkiewicz 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 JaÅkiewicz wrote:
All I know is that xxtea is fixed tea algo. If that fixes weakness in
crypto algo, than so it should make hashing better.
Not necessary. The xtea, xxtea don't fix mixing portion of tea in
accordance with the
following papers: http://algolist.manual.ru/defence/well_kno
-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 re
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
|> accep
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
-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.
|
|>
|> Wou
71 matches
Mail list logo
