Re: 2.6.16-rc6-mm2: slow writes on reiser4.
Le Tue, 21 Mar 2006 23:41:22 -0800, Hans Reiser <[EMAIL PROTECTED]> a écrit : > It may be that we need to port some of > the block allocation optimizations from V3 to V4 (Jeff's work) to help > with 90% full filesystems. Talking of that, I've read about a localized performance problem of reiserfs 3 in backuppc's mailing list (that is otherwise similar in performance with xfs for that task). I wonder if it was ever reported to you, as suggested in this mailing list... http://sourceforge.net/mailarchive/message.php?msg_id=8646808 My understanding is that backuppc is hitting reiserfs3 hard links worse case. Backuppc creates a huge pool of all versions of all files from all backups, compressed, organized using MD5 hashing (handling collisions of course), and hardlinked from their different backup views. [Some metadata is stored separately, so that several files with same content but different metadata can still be shared on disk. But I digress] At night, a sweeping process takes place to remove too old backups (according to user policy), and maybe check if some more background sharing/compression can be done. If I remember well, v3 puts directory entries and their corresponding inodes next to each other on disk. When hardlinks are created, new directory entries are created, pointing to the same inode. If the first directory entry is removed, the inode could be no longer stored near any of the entries pointing to it. Since backuppc is routinely removing directory entries in FIFO order, it's almost guaranteed to happen every time. Hence a very bad inodes distribution on disk after some time... I don't know what xfs does exactly (blocks of preallocated inodes ?) but it does better in this case. Hope it helps, Pierre.
reiserfs 3 on top of software raid 1
Hi all, I have a question that didn't occur to me until a power failure (eh)... When a journalized file system like reiserfs 3 runs on top on a software raid volume, does the volume give enough (and correct) feedback so that the file system can still guarantee that its metadata will be in a consistant state after a power failure/crash/you name it ? If all disks go back online ? If some don't (but below redundancy amount, of course) ? In short, beside disks resynching, is a fsck also necessary ? Best regards, Pierre. -- .-- Concept Micro > | Vente, Maintenance, Conseil & Audit en micro-informatique | email: [EMAIL PROTECTED] ^ web: http://www.concept-micro.com/
Re: Data being corrupted on reiserfs 3.6
Le Sun, 15 Jan 2006 21:36:20 +, Michael Barnwell <[EMAIL PROTECTED]> a écrit : > I'm not sure how to search > through a binary file for non-zero bytes. cmp -b ?
Re: Authoring a versioning plugin
Le Fri, 13 Jan 2006 23:17:06 +0200, Toomas Laasik <[EMAIL PROTECTED]> a écrit : > Hello, > Here are some links that I have found while searching such file systems > that can keep versions or log of changes: While not currently implemented as a filesystem, Subversion repositories look-and-feel is very much like a filesystem. I mention it, because instead of maintaining revisions of each file separately (RCS, then CVS, etc.), it maintains revisions (simple integer counter) of the repository as a whole. It nicely solve the problem of deleted (or simply moved around) files. Tagging versions, creating branches, is handled orthogonally, by copying whole trees in other directories (of course internally everything is just "hardlinked"). What I mean is, that different approach could give ideas on how to implement versionning at filesystem level, or maybe improve a filesystem as a better backend (or frontend ?) to Subversion... Hope it helps, Pierre.
Re: journal size reiserfs vs reiser4
Le Sat, 3 Sep 2005 12:08:46 +0200, Sander <[EMAIL PROTECTED]> a écrit : > Does this mean that if my reiser4 filesystem is 90% full, it can be > considered 85% full wrt performance because of the 5% reservation? 0.9 * 0.95 = 0.855 so it should be 85.5% full if you consider its real physical capacity. (slight difference, only pointing out a common mistake people do when percentages are involved...)
Re: Howto make reiser-3.6 a bit more standby friendly?
Le Tue, 23 Aug 2005 14:39:15 +0200, Clemens Eisserer <[EMAIL PROTECTED]> a écrit : > Hi there, > > I am currently tinkering a idn-router which a harddrive which should > mostly be in stand-by. > However it seems the drive is rather unimpressed by a 5s timeout > setting specified with hdparm and goes in standby very seldom although > the computer is runnig 100% idle (even no isdn-services started or > anything else). Have you tried noflushd ? On recent kernels, it mainly tweaks /proc/sys/vm/dirty_writeback_centisecs...
Re: [PATCH] reiserfs: on-demand bitmap loading (testing only)
Le Thu, 7 Jul 2005 13:59:35 -0400, studdugie <[EMAIL PROTECTED]> a écrit : > I agree w/ Jeff 100%. I'm not a kernel hacker, simply a user. As a > matter of fact, I was one of those people that Jeff aluded to when he > said: "There have been reports of large filesystems taking an > unacceptably long time to mount." That also makes reiserfs uncomfortable with automount devices, specially if they're bandwidth limited like external USB or firewire disks...
Re: reiser4 plugins
Le Fri, 01 Jul 2005 04:08:20 -0500, David Masover <[EMAIL PROTECTED]> a écrit : Hi all, > Metafs also avoids having to patch tar. It's assumed that legacy backup > systems can always avoid metafs and still catch almost everything > important, and certainly everything they already do catch. With a > hybrid or an entirely new backup system, we could catch everything, > including any new ACL-like animals that people invent. As an administrator, a way to perfectly save and restore the content of file systems is a requirement. Crashes do happen, so do migration to new disk subsystems, system cloning, etc, etc. If restoration can be done with the standard tools you find on any live rescue CD, it's even better. All what's probably needed is some readable-writable non-confusing (fully POSIX compliant) "view" that's guaranteed to contain all existing "raw" data and metadata). BR, Pierre.
