Re: reiserfs logging patches udpated
Hans Reiser wrote: Chris Mason wrote: On Thu, 2004-03-25 at 15:41, Mike Fedyk wrote: Chris Mason wrote: On Wed, 2004-03-24 at 22:56, Mike Fedyk wrote: And after having the difference of a block level journal (ext3), instead of a "virtual" journal(reiserfs, jfs, xfs) explained to me (check the ext3-users archives...) -- and how it can save your ass when there are hardware problems. I was convinced and switched everything back to ext3. reiserfs does block based logging ;-) I stand corrected. Thanks Chris, I feel much better about reiserfs now, especially with your ordered/data journaling patches. One other point, the current patch set only does data=ordered. I wanted that fully stabilized before I enabled data=journal. -chris what is a virtual journal? The basic idea of virtual vs block journals, is that instead of using a few bytes to describe what you're changing in (for instance) the inode table (or equivalent), ext3 (and reiser3 thanks to info from Chris Mason) copies entire inode table block (usually 1-4k depending on block size) into the journal.
Re: reiserfs logging patches udpated
Bernd Schubert wrote: However, besides of the proper discussion about the ide problem, there was a 'sub' thread with about 50 messages about the instability of reiserfs!!! I wouldn't be surprised, you get this in the debian lists also. But, the thing is... I wouldn't trust my data to any filesystem without a data=ordered mode. I've used reiserfs on a few systems and it does have a speed increase, but the journaling is like ext2 -- it just journals what it has done, there is no ordering performed *at all* (that is until Suse's data=X journaling patches for reiser3). Adding the fact that reiserfsck3 is just recently getting out of beta level quality (crashes, livelocks & etc during fsck and etc were common until the last few months) And after having the difference of a block level journal (ext3), instead of a "virtual" journal(reiserfs, jfs, xfs) explained to me (check the ext3-users archives...) -- and how it can save your ass when there are hardware problems. I was convinced and switched everything back to ext3. The basic idea of virtual vs block journals, is that instead of using a few bytes to describe what you're changing in (for instance) the inode table (or equivalent), ext3 copies entire inode table block (usually 1-4k depending on block size) into the journal. Where this can save your ass is where some power or other hardware problem caused your drive to overwrite one of your inode tables (or bitmaps or...). Well, some of your data will be corrupted, but if that inode table was written to relatively recently, it'll be restored from the journal during recovery. Yes, I saw speed increases with reiserfs3, but I *will not* use it with critical systems that don't have a power backup and raid system (since reiserfs3 really sucks at handling bad blocks). If I get the time, I'll help test the reiser3 patches in -mm. Thank you Chris for working on this direly needed patch, I'll feel comfortable with my systems running reiser3 once they're running with this patch. Mike
Re: Desktop Filesystem Benchmarks in 2.6.3
cami wrote: I've had ext3 corruptions of note.. Running ext3 on squid's caching partition (expensive hardware + raid1+0 setup), what i'd have was if any proccess wrote to that caching partition, it would lock up the process.. even an rm on any file inside that partition would lock up rm.. after shutting down the machine, and _reformatting_ that partition with mkfs, it *still* done the same thing.. After getting fed up being unable to resolve the problem, Did you post to the ext3-users list on this? Live/Production machines leave very little time for proper debugging.. (so to answer your question, no..) I would still suggest you post to the list to see if there is a solution. That allows you to try it on another machine, or do something different if you setup a new production machine. Were your processes stuck in "D" state, or did you have high systems times? Even with the machine rebooted, i was still experiencing the same thing.. That doesn't say much. If you have corruption on disk, you might get this. If so, you could have configured squid to put fewer files in each directory, or use the htree patch (for 2.4 kernels) or it's in by default in 2.6. Doesnt make much sense, even when reformatting the disk with ext3 again, proved to be useless.. After about 20 seconds with squid running, the same issues would arise.. The machine was up for about 40 days before the issues occured.. What kernel version was this on? Mike
Re: Recommended Journal Size for Small FS?
Jared Warren wrote: (Please excuse me if this has already been answered, I couldn't find anything pertinent in a brief archive search.) I would like to use ReiserFS on my / filesystem, which includes bin, etc, lib, sbin, and root. Right now the files on that partition only take up 40 MB, so it seems like a 32 MB journal is overkill. Some comments I've read recommend using ext3 on small file systems because supposedly the journal is proportional (I have been unable to find out what proportion), however I It should be less than 5MB (I think ext3's mkfs will scale down to 1 or 2MB depending on size).
Re: Formatted over NTFS
David Nielsen wrote: [ David, please keep this on the list... ] Mike Fedyk wrote: David Nielsen wrote: Hi.. i was installing gentoo the other day, and by mistake did a mkreiserfs /dev/hda1 instred of /dev/hdc1 :( /dev/hda1 was a NTFS file system with a lot of data that i dont wat to lose , is there any way to "unformat" the new reiserfs filesystem i made or any way to just restore the files on the disk ? mkreiserfs doesn't write a lot to the disk, so maybe you can just mount it as ntfs and see what you can recover (unless mkreiserfs wrote over your MBT file...) Try the userspace ntfs tools, or even windows >= NT
Re: Formatted over NTFS
David Nielsen wrote: Hi.. i was installing gentoo the other day, and by mistake did a mkreiserfs /dev/hda1 instred of /dev/hdc1 :( /dev/hda1 was a NTFS file system with a lot of data that i dont wat to lose , is there any way to "unformat" the new reiserfs filesystem i made or any way to just restore the files on the disk ? mkreiserfs doesn't write a lot to the disk, so maybe you can just mount it as ntfs and see what you can recover (unless mkreiserfs wrote over your MBT file...)
Re: We shouldn't get this!
Michael James wrote: Dear Reiserfs Listers, I'm sending this from another (unsubscribed) account. If you are reading this then the list takes submissions from anybody. No wonder there is so much viagra peddled here, it needs tightening. It's not a help/tech list unless it accepts emails from the unsubscribed. michaelj PS: Dear list moderator, If you find this quarantined in the "Post by a non-subscriber" basket just delete it, you DO have the list tight enough. Do *you* want to moderate the list?
Re: Snapshot against 2.6.1 released.
On Tue, Jan 20, 2004 at 02:11:45AM -0800, Paolo Correnti wrote: > P.S. Of course, pay attention to have always a "backup > partition" to be able to copy all your Reiser4 data > before testing new snapshots. Right, and keep a copy of the data from *before* you copied the data on that non-reiser4 partition. If you have another empty filesystem around for scratch data, you can use reiser4 for that, but not for data you care about.
Re: Snapshot against 2.6.1 released.
On Tue, Jan 20, 2004 at 12:47:20AM +0100, Redeeman wrote: > the love kernel patch provides reiser4 What else does this unknown patch do?
Re: request for comments (attachment really added now....), proposal to isolate processes using views for greater security
On Thu, Jan 15, 2004 at 01:32:45PM +0300, Hans Reiser wrote: > this proposal is due in a few hours. > > It occurred to me that maybe others might also find it interesting to > sponsor I really think that this could be used to make Linux > distributions a lot more secure, especially if applied to every process > that accepts remote connections Oh, really? Maybe there's a third message I haven't seen yet with the attachment?
Re: Furure of ReiserfsV3?
On Thu, Oct 30, 2003 at 07:03:20PM +0800, Thomas Graham wrote: > Very interesting for your suggestion, does anyone got a benchmark to > compare XFS with reiserfs3 for large amount data process ? ( I am talking > about 20-30GB data pulling at once ) Thanks XFS Will most likely win that benchmark.
Re: new reiser4 snapshot
On Mon, Oct 20, 2003 at 01:44:22PM +0400, Nikita Danilov wrote: > Carl-Daniel Hailfinger writes: > > I thought CONFIG_REISER4_LARGE_KEY was force-enabled by now? > > No. But: > > 1. one has to use -o key=key_short option for mkfs.reiser4 to create > file system with small keys. > > 2. lately we mostly test/care about large keys performance and > stability. So why would one want short keys in the first place then?
Re: New reiser4 snapshot (2003.09.12) is out
On Sat, Sep 13, 2003 at 07:59:51AM -0400, Robert P. J. Day wrote: > p.s. FYI, the clinical definition of insanity is "the fixation that > doing the same thing repeatedly will somehow produce different results." Heh, there are many things where doing the same thing repeatedly will produce different results. Though, you usually have to look at it on a small scale. (twist, twist, twist, twist, twist, slip. Ok now the screw is tight.) ;)
Re: software packaging and ReiserFS v4
On Fri, Sep 05, 2003 at 10:18:06PM +0200, Ragnar Kj?rstad wrote: > On Fri, Sep 05, 2003 at 12:44:13PM -0700, Mike Fedyk wrote: > > On Fri, Sep 05, 2003 at 01:15:41PM -0500, Grant Miner wrote: > > > If you are making a packaging system, I recommend you do not allow > > > scipts, since they open up a whole can of worms. (They're impossible to > > > invert, introduce security problems, make additional work for GUI > > > package managers, and cause too many problems.) > > > > What do you replace them with then? > > I think if scripts were to be removed from the packaging system you > would have to add a package-feature for every single thing that scripts > are currently used for. > > If you look through a collection of packages I think you will find that > they typically do things like: > - create users > - start / stop deamons > and so on. > > So the package-system would need a way to specify that a user is part of > the package (that would be very easy with a /etc/passwd.d-system) and > that deamons that are part of the package should be started at install > and stopped at uninstall-time. > > There are probably dozens of other examples of common operations - and > you would not be able to remove the script-feature unless 99% of what > they are used for is not needed anymore - so it's a complicated task. Great, so now you have a scripting language in the installer. What did you just achieve? If you want gui integration of the scripts, just make nice wrappers of the standard unix utilities that create a window saying "creating user x", or prompting the user for data, or printing a notice. You could probably even take the ncurses library, and add the wrappers there. But let the people who want to do this choose the best way...
Re: software packaging and ReiserFS v4
On Fri, Sep 05, 2003 at 01:15:41PM -0500, Grant Miner wrote: > If you are making a packaging system, I recommend you do not allow > scipts, since they open up a whole can of worms. (They're impossible to > invert, introduce security problems, make additional work for GUI > package managers, and cause too many problems.) What do you replace them with then?
Re: dbench regression in 2.6
On Wed, Sep 03, 2003 at 01:46:13PM -0500, Steven Pratt wrote: > Is anyone looing into the dbench multitheaded regression in 2.6 that I > reported here a couple of weeks ago? I don't see any change in the > latest trees. > > http://ausgsa.ibm.com/projects/l/ltcperformance/2003benchmarks/regression/results/history-graphs/dbench.reiser.throughput.plot.16.png > host ausgsa.ibm.com ausgsa.ibm.com does not exist, try again
Re: dbench regression in 2.6
On Wed, Sep 03, 2003 at 01:46:13PM -0500, Steven Pratt wrote: > Is anyone looing into the dbench multitheaded regression in 2.6 that I > reported here a couple of weeks ago? I don't see any change in the > latest trees. > > http://ausgsa.ibm.com/projects/l/ltcperformance/2003benchmarks/regression/results/history-graphs/dbench.reiser.throughput.plot.16.png > If it's only in dbench, it may not be a problem per say. Dbench does best when there is less fairness. Check the latest posts of contest. There are about 7 improvements with about 3 regressions. Dbench regression by itself doesn't really mean a bad thing happened.
Re: reiser4 debugging status info
On Fri, Aug 15, 2003 at 08:14:18PM +0400, Nikita Danilov wrote: > Hans Reiser writes: > > nobody ever read that, and I think the mailing list is much more > > appropriate than the website, because the website had problems with > > being obsolete when it had the News section. > > I think best way to settle this is to ask list readers. :) Please post to the list...
Re: Filesystem Tests
On Wed, Aug 06, 2003 at 08:45:14PM +0200, Diego Calleja Garc?a wrote: > El Wed, 6 Aug 2003 11:04:27 -0700 Mike Fedyk <[EMAIL PROTECTED]> escribi?: > > > > > Journaled filesystems have a much smaller chance of having problems after a > > crash. > > I've had (several) filesystem corruption in a desktop system with (several) > journaled filesystems on several disks. (They seem pretty stable these days, > though) > > However I've not had any fs corrution in ext2; ext2 it's (from my experience) > rock stable. > > Personally I'd consider twice the really "serious" option for a serious server. I've had corruption caused by hardware, and nothing else. I haven't run into any serious bugs. But with servers, the larger your filesystem, the longer it will take to fsck. And that is bad for uptime. Period. I would be running ext2 also if I wasn't running so many test kernels (and they do oops on you), and I've been glad that I didn't have to fsck every time I oopsed (though I do every once in a while, just to make sure).
Re: Filesystem Tests
On Wed, Aug 06, 2003 at 07:37:42PM -0400, Timothy Miller wrote: > > > Hans Reiser wrote: > > >reiser4 cpu consumption is still dropping rapidly as others and I find > >kruft in the code and remove it. Major kruft remains still. > Now, if you can manage to make it twice as fast while NOT increasing the > CPU usage, well, then that's brilliant, but the fact that ReiserFS uses > more CPU doesn't bother me in the least. Basically he's saying it's faster and still not at its peak effeciency yet too.
Re: ReiserFS problems
On Wed, Aug 06, 2003 at 09:36:23PM +0200, Rogier Wolff wrote: > P.S. We also sometimes do: > > while (1) > seek to random position (in randomly chosen 1G file) > write 1k > > we might benefit from a call that tells the filesystem: > Pretend that this file WILL grow to 1Gb, but leave it sparse for > now. > > So, the block to allocate if we seek to 500Mb past the beginning of the > file would be 500Mb further along the disk. That way the eventual image > will be linear. But leaving the intermediate blocks unallocated will > allow us to eventually use up that free space if we DO NOT end up > writing that area. Ahh, but sparse files are not handled effeciently at all with reiserfs. It is fixed properly in reiser4 though. There was a thread recently on this issue on the reiserfs list within the last week about this. If you use reiserfs, avoid large sparse files like the plague.
Re: Filesystem Tests
On Wed, Aug 06, 2003 at 06:34:10PM +0200, Diego Calleja Garc?a wrote: > El Wed, 06 Aug 2003 18:06:37 +0400 Hans Reiser <[EMAIL PROTECTED]> escribi?: > > > I don't think ext2 is a serious option for servers of the sort that > > Linux specializes in, which is probably why he didn't measure it. > > Why? Because if you have a power outage, or a crash, you have to run the filesystem check tools on it or risk damaging it further. Journaled filesystems have a much smaller chance of having problems after a crash.
Re: ReiserFS on a flash device?
On Sun, Jul 27, 2003 at 02:55:31PM +0400, Yury Umanets wrote: > Default journal size is too big (32MB) for usual embedded device. I > mean, that flash is expensive and it is pity to loss 32MB for journal :) What? You mean it isn't reduced in size based on block device size like with ext3? IIRC, it defaults to 2-4MB on a 100MB device.
[reiserfs-list] Re: [PATCH] radix-tree pagecache for 2.4.19-pre2-ac2
On Sun, Mar 03, 2002 at 11:55:57PM -0500, Ed Tomlinson wrote: > On March 3, 2002 03:03 pm, Christoph Hellwig wrote: > > I have uploaded an updated version of the radix-tree pagecache patch > > against 2.4.19-pre2-ac2. News in this release: > > > > * fix a deadlock when vmtruncate takes i_shared_lock twice by introducing > > a new mapping->page_lock that mutexes mapping->page_tree. (akpm) > > * move setting of page->flags back out of move_to/from_swap_cache. (akpm) > > * put back lost page state settings in shmem_unuse_inode. (akpm) > > * get rid of remove_page_from_inode_queue - there was only one caller. (me) > > * replace add_page_to_inode_queue with ___add_to_page_cache. (me) > > > > Please give it some serious beating while I try to get 2.5 working and > > port the patch over 8) > > Got this after a couple of hours with pre2-ac2+preempth+radixtree. > Can you try again without preempt?
