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'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, it isn't. Reiser4 is an alternative beast. Or will it transparently fix the collision problem in a 3.5 or 3.6 file system, in a way that is backwards compatible with 3.6 drivers? If not, please fix reiser3.6. Given that Reiser4 isn't proven yet in the field (for that, it would have to be used as the default file system by at least one major distributor for at least a year), it is certainly not an option for servers _yet_. A file system that intransparently (i. e. not inode count or block count) refuses to create a new file doesn't belong on _my_ production machines, which shall migrate away from reiserfs on the next suitable occasion (such as upgrades). There's ext3fs, jfs, xfs, and in 2006 or 2007, we'll talk about reiser4 again. Yes, I am conservative WRT file systems and storage. -- Matthias Andree
RE: Congratulations! we have got hash function screwed up
Hello Matthias, 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)? I don't think I'd wait for a distributor to shove reiser4 down my throat, just because the distributor seems to trust it, so the logical course would be for me to try it out. I'll grant you that I am not using it on the mission critical server, because our hosting provider will not support it (ext3 addicts..oh well) but I do have it on my development server, that does house critical code and receives all kinds of hammering from yours truly; And I use it at home. I suppose my point is, filesystem testing and adoption belongs to the masses be they your average Joe Linux user or a sysadmin who feels confident enough in the filesystem's abilities to take the plunge. I run reiser4, I'm happy with it, it is stable enough to carry out my *own* activities. Happy holidays, Yiannis. -Original Message- From: Matthias Andree [mailto:[EMAIL PROTECTED] Sent: 30 December 2004 10:23 To: Hans Reiser Cc: reiserfs-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'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, it isn't. Reiser4 is an alternative beast. Or will it transparently fix the collision problem in a 3.5 or 3.6 file system, in a way that is backwards compatible with 3.6 drivers? If not, please fix reiser3.6. Given that Reiser4 isn't proven yet in the field (for that, it would have to be used as the default file system by at least one major distributor for at least a year), it is certainly not an option for servers _yet_. A file system that intransparently (i. e. not inode count or block count) refuses to create a new file doesn't belong on _my_ production machines, which shall migrate away from reiserfs on the next suitable occasion (such as upgrades). There's ext3fs, jfs, xfs, and in 2006 or 2007, we'll talk about reiser4 again. Yes, I am conservative WRT file systems and storage. -- Matthias Andree This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. Note:__ This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Jaguar Freight Services and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs.
Re: Congratulations! we have got hash function screwed up
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/, 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 for serious work. I don't think I'd wait for a distributor to shove reiser4 down my throat, just because the distributor seems to trust it, so the logical course would be for me to try it out. I'll grant you that I am not using it on the mission critical server, because our hosting provider will not support it (ext3 addicts..oh well) For practical recovery reasons (error on root FS after a crash), ext3fs is easier to handle. You can fsck the (R/O) root partition just fine (e2fsck then asks you to reboot right away); for reiserfs, you'll have to boot into some emergency or rescue system... but I do have it on my development server, that does house critical code and receives all kinds of hammering from yours truly; And I use it at home. I reformatted my last at home reiserfs an hour ago and unloaded the reiserfs kernel module, as the way how Hans has responded to the error report is inacceptable. 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. -- Matthias Andree
Re: Congratulations! we have got hash function screwed up
-- 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 philosophy on file system selection are yours to enjoy as you see fit, but the anger and angst ... ? Phew!! cheers, Cal
RE: Congratulations! we have got hash function screwed up
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 for serious work. 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? For practical recovery reasons (error on root FS after a crash), ext3fs is easier to handle. You can fsck the (R/O) root partition just fine (e2fsck then asks you to reboot right away); for reiserfs, you'll have to boot into some emergency or rescue system... No biggie for me, just have a removable media of some sort with your running kernel and some basic tools. Y. Note:__ This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Jaguar Freight Services and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs.
Re: Congratulations! we have got hash function screwed up
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 bug-free. I don't expect NFS problems with reiser4 though, these should be in the regression tests. :-) -- Matthias Andree
Re: Congratulations! we have got hash function screwed up
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 reiserfs3. End of story. Your policy and philosophy on file system selection are yours to enjoy as you see fit, but the anger and angst ... ? Phew!! I have no interest to deal with systems that have known and reproducible cases of failure that are nondeterministic in practical use. And Marc's documentation showed this is a real-world problem, not an ivory tower problem. The reiserfs story is over for me. All private machines I deal with are reiserfs-free as of a few hours ago. It was just one bug too many, and it was handled unprofessionally, unlike many bugs before which had been dealt with on short notice usually, or at least accepted for looking into. I'll phase reiser3 out on my work machines as I see fit. I have seen too many bugs in reiserfs3. I do believe reiserfs4 fixes some design flaws of reiser3, and when the implementation issues are all shaken out in one or two years' time, it may be a good file system and I will look at it - I trust the reiserfs team can learn from their mistakes. I hope they learn that THIS handling of the error was wrong. Who cares, not us for the past five years is not a proper response to a real-world problem. -- Matthias Andree
Re: Congratulations! we have got hash function screwed up
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 far to fix bugs in V4, which is pretty stable these days. Better to fix a known bug than create a file system vacuum before V4 is really stable. Anyways, I don't care any more, I'm phasing out ReiserFS v3 and have no plans to try V4 before 2006. -- Matthias Andree
Re: Congratulations! we have got hash function screwed up
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 true, you are right. Reiser4 is the fix though. So that what happens to the filesystems develop once you have a new toy. Good to know when planning my next server :) (Even if it were ok to fail file creation, the error generated is still wrong. It is a bug, no matter how you try to twist it). Blame Alan Cox for that, he changed it from -EHASHCOLLISION (or some such error I invented, I forget) over my objections. Blaming Cox for trying to fix your code and not getting it completely right is not nice. After all, Cox also found that the error code is inadequate. The point is that EBUSY is still bad, for open. ENOSPC is a much better code, as it is a documented error code for open, whereas EBUSY is not. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Re: Congratulations! we have got hash function screwed up
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 get back what they mistakenly removed. It shouldn't be hard with reiserfs either. There should be a selection of what files to restore, so we can avoid the file merging problem with rebuilding the tree from leaf nodes. I have seen too many bugs in reiserfs3. Is there a list of these current issues? Who cares, not us for the past five years is not a proper response to a real-world problem. I also reacted to this response. A flaw in the filesystem, in my opinion, is equivalent to the space ship crashing and all crew members die. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
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)? 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. The reasoning in fact is that file systems which are out in the field for years have _known_ properties, are proven to work with some amount of software, possibly including software that specicially has workarounds for filesystem shortcomins (i.e. squid with it's multi-dir-hierarchy, which is just a workaround for basically all non-reiserfs filesystems, and now also for reiserfs3 filesystems, which also doesn't cope with millions of files in a dir, as opposed to the original claims by it's developers). This is cerftainly true for microsofts filesystems: you know what to expect from vfat or ntfs, for example. For new filesystems, the issue is completely different. Look at the file is a directory approach that formerly was the default in reiserfs. This breaks a number of programs, despite the expectancy by the reiserfs authors that this is not the case (in my experience, stat path/. to quickly check wether sth. is a file or a directory is pretty common). Unless the filesystem is in the field for some time these bugs will not be found. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Re: Congratulations! we have got hash function screwed up
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 reiserfs-4 either. I see desperate users all the time trying to get back what they mistakenly removed. It shouldn't be hard with reiserfs either. There should be a selection of what files to restore, so we can avoid the file merging problem with rebuilding the tree from leaf nodes. I have seen too many bugs in reiserfs3. Is there a list of these current issues? Who cares, not us for the past five years is not a proper response to a real-world problem. I also reacted to this response. A flaw in the filesystem, in my opinion, is equivalent to the space ship crashing and all crew members die. To be more exact, it's equal to a mars probe stranding and making many scientists very nervous :-) -- Regards, Christian Iversen
RE: Congratulations! we have got hash function screwed up
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 distribution. It can be proven good or proven bad :) Clear?:) [..]Unless the filesystem is in the field for some time these bugs will not be found. I agree but only if the filesystem is used in the real world, and it's adoption is not driven primarily by distributors. BTW red|purple|brown might as well be black if you are colour blind ;))) It's all a mater of perception. Note:__ This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Jaguar Freight Services and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs.
Re: Congratulations! we have got hash function screwed up
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 ;-) Maybe you can clue them in the wonderful world of making backups? Next time it is not their mistake, but instead a broken harddisk. Undelete wont save them then. Or they just edited it instead of rm.
Re: Congratulations! we have got hash function screwed up
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 dance. 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. Or they just edited it instead of rm. This is handled in user space. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
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 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. And restore from backup is always quicker and less stressful on the nerves. Or they just edited it instead of rm. This is handled in user space. Maybe in your situation. But in general I advice everybody to make backups. Might also be the reason nobody wrote a reiser4 undelete plugin yet.
Re: reiser4 for 2.6.10 and reiser4 update for 2.6.10-rc3-mm1
Vladimir Saveliev wrote (ao): you can get latest reiser4 for 2.6.10 (ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.10/reiser4-for-2.6.10-1.gz) and update for 2.6.10-rc3-mm1 (ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.10-rc3-mm1/reiser4-update-for-2.6.10-rc3-mm1-1.gz). Thank you all! Was looking forward to it. Will this update also be in the next -mm kernel? Does this update make reiser4 ready for Opteron systems?
Re: Congratulations! we have got hash function screwed up
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 not be hard to implement. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
RE: Congratulations! we have got hash function screwed up
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 cheap. Recovery is very expensive. Ask the CIA ;-) It's Hans and friend's responsibility to patch whatever looks like a serious problem. It's the user's responsibility to protect valuable data. File system reliability after that is really a question of operational downtime expenses etc. If people don't trouble themselves to perform backups: 1. They have accepted that risk or 2. They are too junior to have ever lost a couple months worth of work because they were too lazy or inexperienced to perform backups. 3. They don't have any work that can't be rebuilt in a matter of hours (see #1). (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 granted, like that fact that the person we're talking to looks really tired etc. Unlike ext3, XFS and JFS, Reiser isn't funded by someone with huge pockets.) Jim Burnes
Re: reiser4 for 2.6.10 and reiser4 update for 2.6.10-rc3-mm1
Hello On Thu, 2004-12-30 at 21:32, Sander wrote: Vladimir Saveliev wrote (ao): you can get latest reiser4 for 2.6.10 (ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.10/reiser4-for-2.6.10-1.gz) and update for 2.6.10-rc3-mm1 (ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.10-rc3-mm1/reiser4-update-for-2.6.10-rc3-mm1-1.gz). Thank you all! Was looking forward to it. Will this update also be in the next -mm kernel? We sent reiser4 update to Andrew Morton. So, it should. Does this update make reiser4 ready for Opteron systems? This update does not contain anything specific for Opteron. Do you have any problmes with reiser4 on it? We are about to get such system for tests, but probably after New Year.
Re: Congratulations! we have got hash function screwed up
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 ;-) Maybe you can clue them in the wonderful world of making backups? This is the standard Linux comment... But in reality, it just a way to say you do not know, or that linux lacks an (in this users opinion) important feature. 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 Reiser where there is tailing etc for small files this can be a problem. Either the little file might not be able to be recovered (shouldn't the data still exist, even if it is tailed), or the user need to use a non-tailing policy? Next time it is not their mistake, but instead a broken harddisk. Undelete wont save them then. Indeed. Backups are important. But the backup does not recover the last minute changes. They may be a day or a week old at best - even at larger sites! Or they just edited it instead of rm. ´ well, overwritten data is not so easy to get back. But from what I understand in Linux, is that many applications actually write another file and then unlinks the old file? If that is the case then it may even be possible to get back some overwritten files! ~S --
Re: Congratulations! we have got hash function screwed up
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 shop. We got IBAS in Norway; the price for an evaluation is close to a handful of gold. Backups are cheap. Recovery is very expensive. 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. Besides, a recovery is not the same as a feature to undelete. Such a feature would maybe save a days work, which is a lot in some circles. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
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 problem of the hd then?. Why couldn't the dutchies do the job? And restore from backup is always quicker and less stressful on the nerves. Like I said to James, this might not only be the fault of the user. Maybe in your situation. But in general I advice everybody to make backups. Might also be the reason nobody wrote a reiser4 undelete plugin yet. It's no use to talk about backups when we talk about undelete features; backups are for recovery after nuclear explosions, faulty hardware which makes it inaccessible to even retrieve data out of it or something similar. 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 tree again. It's not like reiserfs overwrites this data, it's still there, so why should there be an artificial barrier to getting this data back?. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
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 tree again. It's not like reiserfs overwrites this data, it's still there, so why should there be an artificial barrier to getting this data back?. You're using the wrong tool for the job. For what you're asking for you want Plan 9 and its wormfs. Thanks for playing. -- 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
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 problem of the hd then?. Why couldn't the dutchies do the job? Maybe the Dutch company is not that good :-) It could be IBAS, but they didn't mention a company name. It has to be a well know one. And your mention of gold in your other mail is very true of course :-) 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 tree again. It's not like reiserfs overwrites this data, it's still there, so why should there be an artificial barrier to getting this data back?. 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 much needed pointers to the data.
Re: reiser4 for 2.6.10 and reiser4 update for 2.6.10-rc3-mm1
Hello. Vladimir Saveliev wrote: Hello you can get latest reiser4 for 2.6.10 (ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.10/reiser4-for-2.6.10-1.gz) and update for 2.6.10-rc3-mm1 (ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.10-rc3-mm1/reiser4-update-for-2.6.10-rc3-mm1-1.gz). sorry, this is vs's typo, the newest update for 2.6.10-rc3-mm1 is ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.10-rc3-mm1/reiser4-update-for-2.6.10-rc3-mm1-2.gz Thanks, Lena. Elena, please try to hammer it. Happy new year!
Re: Congratulations! we have got hash function screwed up
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 granted, like that fact that the person we're talking to looks really tired etc. Unlike ext3, XFS and JFS, Reiser isn't funded by someone with huge pockets.) I'm willing to grant ANY time-out, if Hans wrote I have a pile of deadline reiser4 contract work before I can deal with that, fine, he didn't but said use reiser4 instead. And that's inadequate. And I say this without any emotions, red head, swelling veins and such. -- Matthias Andree
Re: Congratulations! we have got hash function screwed up
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 does. Besides, a recovery is not the same as a feature to undelete. Such a feature would maybe save a days work, which is a lot in some circles. Backup more often. Staged backup schemes (hourly, daily, weekly, monthly) with varying levels of differential or complete backups, plus off-site archives, are probably a good idea for these circles then. -- Matthias Andree
Re: Congratulations! we have got hash function screwed up
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 much needed pointers to the data. I'm not talking about grep here. I'm talking about a reiser tool to scan the partition for metadata and use this to recover the file by putting it back in the tree. Methods like grep is an absolute last resort, if, like in this case, there is no tool that does the job. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
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 about it and not him.;-) I see desperate users all the time trying to get back what they mistakenly removed. It shouldn't be hard with reiserfs either. There should be a selection of what files to restore, so we can avoid the file merging problem with rebuilding the tree from leaf nodes.
Re: Congratulations! we have got hash function screwed up
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.
Re: Congratulations! we have got hash function screwed up
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 shop. Backups are cheap. Recovery is very expensive. Ask the CIA ;-) It's Hans and friend's responsibility to patch whatever looks like a serious problem. It's the user's responsibility to protect valuable data. File system reliability after that is really a question of operational downtime expenses etc. If people don't trouble themselves to perform backups: 1. They have accepted that risk or 2. They are too junior to have ever lost a couple months worth of work because they were too lazy or inexperienced to perform backups. 3. They don't have any work that can't be rebuilt in a matter of hours (see #1). (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 granted, like that fact that the person we're talking to looks really tired etc. Unlike ext3, XFS and JFS, Reiser isn't funded by someone with huge pockets.) Jim Burnes It seems a bit more shows than I would like. My wife just got some 75 year old female judge filling in during the christmas holidays for the regular judge to take my kids away from me, without me getting a chance for a response to the allegations, until a hearing in 25 days from now, because I show my son movies about world war II, and my exposing him to violent computer games is alleged to induce traumatic stress disorder which somehow has never been reproduced in front of me. Only in California. I shall be alleging that little boys take to violent computer games like monkeys take to trees, and challenging anyone to reproduce in front of me evidence to the contrary.
Re: Congratulations! we have got hash function screwed up
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..
Re: Congratulations! we have got hash function screwed up
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 crash. Please think before you post. -- ciao - Stefan GNU's Not Unix --IIS Isn't Secure
Re: Congratulations! we have got hash function screwed up
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 filesystem.. ... that causes the space ship to crash. Please think before you post. he's talking about the value of human life vs. some data. --
Re: Congratulations! we have got hash function screwed up
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]
Re: Congratulations! we have got hash function screwed up
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 Reiser where there is tailing etc for small files this can be a problem. Either the little file might not be able to be recovered (shouldn't the data still exist, even if it is tailed), or the user need to use a non-tailing policy? 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 - but then don't complain about space efficiency. well, overwritten data is not so easy to get back. But from what I understand in Linux, is that many applications actually write another file and then unlinks the old file? If that is the case then it may even be possible to get back some overwritten files! I see enough applications to just overwrite an output file. This whole discussion doesn't belong here until someone talks about implementing a whole versioning system for reiser4. -- Matthias Andree
Re: Congratulations! we have got hash function screwed up
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 Reiser where there is tailing etc for small files this can be a problem. Either the little file might not be able to be recovered (shouldn't the data still exist, even if it is tailed), or the user need to use a non-tailing policy? 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 - but then don't complain about space efficiency. Yes, When data is overwritten then it is overwritten. The longer the user waits to try to recover data, the more risk of this happening. Undelete has existed a long time and people know it is not a foolproof thing. I do not think anyone asked for automatic backup features, but just tools that can try to recover accidental deletions. well, overwritten data is not so easy to get back. But from what I understand in Linux, is that many applications actually write another file and then unlinks the old file? If that is the case then it may even be possible to get back some overwritten files! I see enough applications to just overwrite an output file. Yes, This was an example only. In any case. If there were tools that could scan and recover, even partly, deleted files then I would welcome them. I am sure lots of other people do too. It is very easy to say you need backups of your data, that you need versioning filesystems etc. But not all of this is possible for everyone. Just take a laptop as example. Making backups is not so easy to do frequently - especially not when traveling. Sure, if you run in a corporate environment you can do shadow copying or use other versioning systems and mount that over the network. But for the normal home or small business users this is not really what you can expect... This whole discussion doesn't belong here until someone talks about implementing a whole versioning system for reiser4. I think someone said they wanted undelete recovery features in reiser4 - which was what started this discussion? ´ --
Re: reiser4 for 2.6.10 and reiser4 update for 2.6.10-rc3-mm1
Hello, I applied reiser4-update-for-2.6.10-rc3-mm1-2.gz on top of my 2.6.10-rc3-mm1 tree and then tried to compile : linux-2.6$ make [...] Building modules, stage 2. MODPOST *** Warning: find_get_pages [fs/reiser4/reiser4.ko] undefined! *** Warning: find_get_pages_tag [fs/reiser4/reiser4.ko] undefined! LD [M] fs/reiser4/reiser4.ko linux-2.6$ grep REISER4 .config CONFIG_REISER4_FS=m # CONFIG_REISER4_CHECK is not set The following patch fixed it : --- linux-2.6/mm/filemap.c~ 2004-12-13 22:15:33.074988832 +0100 +++ linux-2.6/mm/filemap.c 2004-12-31 00:20:21.760733816 +0100 @@ -636,6 +636,7 @@ unsigned find_get_pages(struct address_s read_unlock_irq(mapping-tree_lock); return ret; } +EXPORT_SYMBOL(find_get_pages); /* * Like find_get_pages, except we only return pages which are tagged with @@ -657,6 +658,7 @@ unsigned find_get_pages_tag(struct addre read_unlock_irq(mapping-tree_lock); return ret; } +EXPORT_SYMBOL(find_get_pages_tag); /* * Same as grab_cache_page, but do not wait if the page is unavailable. ~~ laurent signature.asc Description: OpenPGP digital signature
nvram to protect fs during power loss?
There have been some discussions about recovery abilities during power loss if write cache is enabled. Some recovery tool I saw once used NVRAM to store progress info so that if you had a power loss it would be able to resume. Perhaps it would be possible for Reiser4 to store some info, like time indexes etc in NVRAMwhen it send sync commands to the disk. This way it might be possible to avoid corruptions by simply verifying (fsck) the data stored after that time index etc? I have no idea how often NVRAM can be written to before it goes bad. Is there a limit? ~S --
Re: Congratulations! we have got hash function screwed up
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 let the users know about it and not him.;-) He has some good points, though. If you're going to have a kernel, you want to keep it small, put stuff in only if it needs to be there. And how much speed do we lose by putting stuff in userspace, if we do it right? C'mon, if Doom 3 can run in userspace, surely some sort of trash can / recycle bin can, right? Oh wait... Gnome/KDE already do that.
reiser4 read performance loss of 17% in latest -mm kernel
Just an FYI, we are still figuring it out. andrew, you might note it in release notes, especially if we don't fix it before your next release.
Re: Congratulations! we have got hash function screwed up
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 him.;-) I'll just let the users know about it and not him.;-) He has some good points, though. If you're going to have a kernel, you want to keep it small, put stuff in only if it needs to be there. And how much speed do we lose by putting stuff in userspace, if we do it right? C'mon, if Doom 3 can run in userspace, surely some sort of trash can / recycle bin can, right? Oh wait... Gnome/KDE already do that. the problem being that everyone uses rm not the gnome/kde trashcan literal copying of Apple doesn't work for unix because we use shells most of the time.
--rebuild-tree always finds errors --check is ok
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. --check says all is good.
Re: reiser4 read performance loss of 17% in latest -mm kernel
Hans Reiser [EMAIL PROTECTED] wrote: Just an FYI, we are still figuring it out. andrew, you might note it in release notes, especially if we don't fix it before your next release. I'd try reverting simplified-readahead*.patch.
Re: Congratulations! we have got hash function screwed up
-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, 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 about it and not him.;-) | | | | He has some good points, though. If you're going to have a kernel, | you want to keep it small, put stuff in only if it needs to be there. | And how much speed do we lose by putting stuff in userspace, if we do | it right? C'mon, if Doom 3 can run in userspace, surely some sort of | trash can / recycle bin can, right? | | Oh wait... Gnome/KDE already do that. | | | | the problem being that everyone uses rm not the gnome/kde trashcan | literal copying of Apple doesn't work for unix because we use shells | most of the time. we being people who should be able to back things up and avoid really stupid mistakes, and people who care about performance. But you are right, this has to be lower down -- maybe glibc, maybe vfs, maybe fs views -- because there's no standardization once you get to things like gnome. My point about Doom 3 is that I like the idea of a microkernel, if it could be done fast enough. Games talk to kernel space and hardware very quickly, but it seems kernel-userspace communication isn't fast enough for things like filesystems. Maybe someone can engineer a way around that? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQdTqswisZLIF6uqOAQKczQ/8DeKVlFL5cS+KXnBaq9+w+rBkpak/LRld 1gyIyp4s0mVdpRNTGa5W2YPB0McOZj5TDUVZivAKScbd1srsV1QxlhUxzY6QMUwo 7Y9k+yJbm0J89Tnrap2DJmE/teN40Rw4thY5VyQ5cfugNFZtdrwgRsKqvsxV4cOQ lIOci7SJuLUdgdtfLWORyEdYSe180P9XJMaGTxoVYSnwnBMbXX5C33OOVmJjEvU7 Pevro6GcfOvALj+ciI3AtvhdCbyasrevgfc1K/iZk3MwQFZKXRUtW5LcT1Lwax08 acn4n6f5ZhEQJWarv93EOn0T6KfXuD0uY9GbNRJS/ldPUg4tCaw3RfzVgdvpUVlw uI+hPXsVpEGDyBm1aK3TQ30brUzBx/ILgblQvCe4QuHH5NWb63I0xPKbmqqmCdCR cx06b3cbBCgO6QK3gqURHdyeQjlpJL92EXARmYLFjAnAicnKG95N4QiZsHIIuGvn 9iQcAS0bfU+elPbnfeiJnRTfEU6i1eLwSmsYo0i1m80U58TW604Dcfv2RcQrtluw 96eO9VB++8QWpl2Tv4G7u9yFrmOcx4Vo1tVkbFoPZvsP5sMqY6XhKowX5uWLjkwQ hiAWb57HKxUTaPcW6CyGh+zr8g+Z8Po7TRA1GcdNMZZBfgNcAlZvlSDmOw7BHlMj ixpwaj2lWYU= =Z6t0 -END PGP SIGNATURE-
