Re: reiser4: data recovery after mkfs.reiser4?
On Thu, Dec 21, 2006 at 12:35:04PM +0100, Michael Weissenbacher wrote: > Could someone resend that info to the list? I'm sure others would be > interested too. I just replied I'd try what Vladimir said, and so I did - successfully. But here you go, hoping this one will come through. I even stopped signing my outgoing email to this list, to no avail. For me, fsck.reiser4 -u -O --build-fs $device did the trick. The file system was killed by a scripted mkfs.reiser4 followed by a mount and unmount. Only two files were missing afterwards, while lost+found was globbered with the obvious heap of previously deleted files, most of them being 0 in size. Kind regards, Chris
Re: reiser4: data recovery after mkfs.reiser4?
Hi, On Wed, Dec 20, 2006 at 03:05:33PM -0700, Quinn Harris wrote: > I really doubt there is any solution that would take less than a few > hours. I am sure it is possible to recover much of the data but to > the best of my knowledge no tool exists that can recover from an > abandoned root node (for reiser4). Though I believe recovery in this > case would just involve finding the root node (think that is > reasonably tractable, but slow) fixing the superblock to point to that > and let fsck do its thing. > > I don't think the root node has a magic number that advertises root, > but internal nodes do have a recognizable signature and in principal > one could deduce which is the root from a collection of the internal > nodes. > > Note that reiser4 packs lots of data in single nodes. If you create a > fresh fs with only a few small files they will reside entirely in the > root node, which will be clobbered by a mkfs. There is a very good > change that mkfs will clobber a little bit of data, but less than 4K. > > I am sure a few thousand dollars would buy you a solution. Maybe > less. Thanks for your concern! However, with the additional flags Vladimir mentioned, I managed to recover all but two shared library files which could be easily copied from a working system. I already answered Vladimir's posting twice - one "thanks, I'll try that" and one success report. It just so happens that a LOT of mails I send to the list never gets through, no idea why. Regards, Chris
reiser4: data recovery after mkfs.reiser4?
Hi folks, a buggy script I wrote dared to mkfs a reiser4 partition after failing to properly tar up its contents - not that my life would depend on them, but it would save me a few hours if I could get the stuff back. Other than mkfs.reiser4, mount and unmount, nothing was done to the device ; ) Is there any way to recover most of what was stored on the now nuked fs? TIA, Chris
Re: [PATCH] reiser4: fix readv
On Thu, Sep 14, 2006 at 10:35:02AM +, Peter wrote: > This does not patch against 2.6.17-3 patchset however. Any possibility > this may be related to some startup issues as noted on other threads here? I have seen the issues at bootup you noticed some time ago, but only once after the root fs had been mounted in a different way, i.e. laptop hdd stuffed into a USB case and connected to my desktop, mounted to /mnt/something. The most annoying problems that have been fixed for me were related to gentoo's postfix and spamd startup scripts. For some strange reason, they did not detect properly that postfix had been started / spamd had been stopped. Now everything seems kosher - I survived a few suspend/resume cycles without the hickups that have become common during the last few months. Sadly, I had more serious trouble to worry about, otherwise I had bugged the list myself : P Kind regards, Chris pgpgZzZU2mOck.pgp Description: PGP signature
Re: [PATCH] reiser4: fix readv
Hi Vladimir, this fixes a bunch of random user space oddities for me. Just patched 2.6.18-rc6-mm2 with this, and some annoyances I could not trace back to a change in user space just went bye-bye. Thanks a lot! Chris pgpJBZDdCOUrz.pgp Description: PGP signature
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On Wed, Aug 09, 2006 at 12:01:42AM -0400, David Masover wrote: > A warning isn't good? Would you rather it be an error? Of course not. It merely appears inconsistent to offer a root fs choice that may cause severe problems at bootup time. When I went to install my first SuSE (brand-new 6.1 at that time) I looked up the huge printed manual: what are my options? OK there weren't many at the time ; ) But there was the >1023cyl problem, being a careful guy I opted for a separate /boot at the start of the disk, for example. Better safe than sorry. And if there had been a choice in terms of file systems (ext2 was the only way afair) there would have been a decision as well. Now say I carefully weigh different aspects of different solutions, only to find out that my decision was "not so good" and will possibly cause problems _unless_ I play around with strange mount options that _disable_ some of the features supporting my decision. Knowing trouble lies ahead of course is better than just running into it : ) > Some people would like to test Grub's XFS support... Sure thing. But those might not want to do this on their production machine, anyway, and test something more bleeding-edge than what distros ship at the time. Presuming there is ongoing development, that is. > It's not necessarily broken, just potentially unreliable, and > difficult to work with (you have to set arcane mount options or > somesuch). Same for ReiserFS3, by the way. All that, especially "unreliable", is not something your average user is likely to accept. People have been cursing the whole x86-pc hardware for the mess that mainstream software (M$ mainly, but no need to copy their mistakes) has been for the past two decades. I've been asked by folks more than once if switching to a mac will ease their pain. So what a distro installer wants to do is remove all the options from anything but "expert mode" that might cause the slightest hickup. > Really, while Grub is useful, it's a rather large duplication-of-code > effort. XOSL is even moreso, especially considering it doesn't > support Linux or multiboot natively -- it must boot Grub or Lilo in > order to run Linux or HURD. Why aren't we using kexec for this > already? This is way beyond my knowledge, sorry. But I like kexec a lot, just wonder how to get to the point where kexec can be used _without_ linux up and running already... > It's called "backup and restore." Or did you have a different idea > for how to convert an existing installation to another root FS, or do > a fresh installation without nuking your partitions anyway? Well, there is convertfs, fsconvert (which i.e. _is_ backup&restore), parted, etc. There are ways, some are safe, most are not. But I am afraid we have gone way OT by now. What I had in mind all the way basically was the distro user / end user experience which should be as uncomplicated as possible, while still leaving choices. But when it comes to "advanced" file systems, these choices come at the price of a more sophisticated setup or lack of reliability, as you already pointed out. But how do you explain to a linux newbie: use ext2|3 for / due to bootloader issues _or_ something funky, yet with funkyness partly turned off for bootloader compatibility, _or_ use a tiny ext2 /boot and feel free to fsck&mount as you damn please. Most people just don't care anyway, and those who do will want to know why. And telling them that otherwise it won't work (without extra care) yields the question, "why not?", and you might _not_ want to try explaining the entire situation from within the installer help text. Or maybe that would be the way to go? Who knows how much people actually read in the end, before they just quit - worrying, deciding, or even installing the thing at all. And now, go easy on me! This was never intended as a debate of colliding opinions - call it brainstorming : ) Kind regards, Chris pgpsSTvFCVQnV.pgp Description: PGP signature
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On Mon, Aug 07, 2006 at 01:09:42PM -0400, David Masover wrote: > Christian Trefzer wrote: > > Few people keep a 32MB ext2 for /boot purposes these days, so it > > really is imperative that grub can read kernel images off a reiser4 > > /. > > I think there are patches, but I do keep a 32 meg ext3 for /boot, > because it seems like no matter what FS I choose, there's some sort of > caveat involving Grub. I know when installing XFS as a root FS on > Ubuntu, it talks about Grub problems... New installations is what I had in mind there. People see they could use something fancy, but their bootloader-du-jour won't take it. Bummer. The warning message is the only thing keeping folks from running into a broken installation. No good. > I mean, having Grub support everything would be nice, but if you're > reformatting anyway, I don't think it's that imperative. Yeah, _if_ you are s.o. who knows how to turn a partition table upside down without losing a single bit of data. Even then, it is quite a hassle to move the start of a partition 4 cylinders up to make room for an all-compatible ext2 /boot ; ) Grub is a bootloader and as such should (as an optimum) be able to grab kernels off of any fs. I guess patches are accepted by upstream developers? Kind regards, Chris pgpcCiJHSyAXR.pgp Description: PGP signature
Re: Ebuild/rpm/deb repo's (was Re: reiser4 can now bear with filled fs, looks stable to me...)
On Sun, Aug 06, 2006 at 04:23:16PM +0200, Maciej Sołtysiak wrote: > I tried to create a kernel package with reiser4 for ubuntu-server (dapper) > They ship a 2.6.15 (heavily modified) kernel upon which the current > reiser4-for-2.6.17-3.patch applies fine but unfortunately miscompiles, eg. > fs/reiser4/plugin/file_ops_readdir.c: In function 'llseek_common_dir': > fs/reiser4/plugin/file_ops_readdir.c:486: warning: implicit declaration of > function 'mutex_lock' > fs/reiser4/plugin/file_ops_readdir.c:486: error: 'struct inode' has no member > named 'i_mutex' > fs/reiser4/plugin/file_ops_readdir.c:508: warning: implicit declaration of > function 'mutex_unlock' > fs/reiser4/plugin/file_ops_readdir.c:508: error: 'struct inode' has no member > named 'i_mutex' > > I bet these are trivial to fix and I will try to do this but my time > constraints > currently prevent me from doing that. Guess these won't be so easy, afaik 2.6.15 lacks the semaphore->mutex transition. > There also is an issue with grub. The kernel alone is fine for creating > partitions > (or loop devices) but with grub not patched we can't install boot partitions. > No biggy, > I guess, but still a problem. Few people keep a 32MB ext2 for /boot purposes these days, so it really is imperative that grub can read kernel images off a reiser4 /. > I could create a vanilla + reiser4 kernel package easily but that would be > stripped > off of the important dapper/debian patches and that is a no-no for dapper > users, I guess. > At least for non-guru freaks who run their own, modified kernels. Sure. The best thing might be to back-port "internal" fixes in fs/reiser4/ to reiser4-for-2.6.15-x so the API calls match the kernel. Patching 2.6.15 with a 2.6.17 patch is a no-no. But you _are_ taking a step forward, and your effort is appreciated : D Kind regards, Chris pgpaKpM0N5nTR.pgp Description: PGP signature
Re: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion)
On Mon, Jul 31, 2006 at 06:05:01PM +0200, Łukasz Mierzwa wrote: > I gues that extens are much harder to reuse then normal inodes so when You > have something as big as portage tree filled with nano files wich are > being modified all the time then You just can't keep performance all the > time. You can always tar, rm -fr /usr/portage, untar and You will probably > speed things up a lot. I submitted a script to this list which takes care of everything required to recreate your fs. It even converts between different filesystems, for migration purposes or comparitive tests, and currently supports ext2|3, reiser3|4 and xfs. The thing is undergoing some surgery atm. to reduce forced disk flushes. I already replaced the call to sync() after every operation by one fsync() call on the archive file before the formatting takes place. What is still missing is functionality to retrieve things like fs label and UUID from the existing fs and reuse them during mkfs. Testing is also pending, so you might not want to hold your breath waiting for the funky version, the idea of which is to leave everything as it was found, except for better disk layout and possibly changed fs type. It is a completely different approach from convertfs, which tries to do the conversion in-place by moving the fs's contents into a new fs created within a sparse file on the same device and relocating the sparse file's blocks afterwards. My guess is that a failure of any kind in the latter process will destroy your data (this was the case last time I checked), while I do (at least try) everything to ensure that the tarball is written to platters before mkfs occurs. The new version will be posted to wiki.namesys.com asap, no timeframe attached though as Thursday yields an exam, so maybe on Friday, but who knows. The version already posted to the list works well, I used it at least a hundred times, even on stuff like /home and /usr (the latter works only from a live cd or custom initramfs). Kind regards, Chris pgpJCvRI7J8nt.pgp Description: PGP signature
Re: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion)
On Mon, Jul 31, 2006 at 10:57:35AM -0500, David Masover wrote: > > Wil Reichert wrote: > > >Any idea how the fragmentation resulting from re-syncing the tree > >affects performance over time? > > Yes, it does affect it a lot. I have no idea how much, and I've never > benchmarked it, but purely subjectively, my portage has gotten slower > over time. Delayed allocation still performs a lot better here than the v3 "immediate" allocation. In addition, tree balancing operations are performed on flush as well, so what you get on disk is basically an almost-optimal tree. Of course, this will change a bit over time, but with v4 it takes a lot longer for that to happen than with v3 afaict. There _has_ been some worthwile development in the meantime : ) Kind regards, Chris pgpYfJOp8uyxN.pgp Description: PGP signature
reiser4 can now bear with filled fs, looks stable to me...
Hi, I booted 2.6.18-rc2-mm1 today and later filled up my /opt partition by accident, and guess what, reiser4 did not screw up : D I already planned on forcibly filling up something less depended upon, like the portage tree, but studies kept me from playing and the scheduled java vm update took care of it... Congratulations and thanks to the namesys developers! Hans, I can somewhat understand how you feel about your situation. Don't let frustration get in your way, your work is simply too great. You're an emotional kind of guy - don't get me wrong, so am I and at least once a day I want to run off and knock out some lying politician scum for screwing over society ; ) Sometimes you just have to swallow your pride instead of wasting your time by yelling at the rest of the world, and if "humble work" does not lead to success, there won't be any other way, I fear. IMHO it would be best to deliver "quality patches" against all kinds of sources (distro kernels, vanilla -rcs maybe, etc.) and the entire patched source tarball as well, for people to download and build. Next step would be to provide binary packages, and repos for people to add to their package manager's source list. Until distros pick up their respective patch, this is as far as support can go, I guess. This is not about forking, it's more about providing the service we'd want kernel.org to provide for us and which will possibly happen some time, in some way. If they won't push you, you have to push by yourself, sad but true. This is also _not_ meant as the start of yet another flame war, and $deity be my witness, I won't reply on any non-technical polarizing bullshit, damnit. And this is exactly the reason why I won't cross-post this to LKML, where OT-flames span topics from ext4 over suspend2 to the 2.4-2.5 transition. Some people really do have too much time on their hands. This is about what can be done to bring reiser4 to the users, at least to those who know about differences in file systems. To anybody else, it simply won't matter anyway. So, to get to an end now, as I really need to get some sleep: where do we start? - a git tree might be very helpful in the beginning, separating, in branches, the self-contained source code from the kbuild part that may intersect with diverging modifications in different patchsets/vendor sources. - next we could adapt, in branches forking off of the vanilla kbuild branch, the kbuild-related parts to different distro kernels, maybe even old versions. Troublesome are things like changing APIs, but that can be taken care of and has been in the past. - once we get a source repo that takes into account several distro-patched kernels, we can generate patches with git against those kernel sources, build binary packages, and maybe even binary modules as separate packages for minimal installation effort. Maybe I am a bit too optimistic estimating the amount of work required for this, but seeing a pretty stable (and self-contained!) code base being torn appart to satisfy some obscure need for generalization, which might even yield _no approach towards inclusion_ nonetheless, just makes me feel sick. I personally don't care about new semantics as long as they are absolutely backwards-compatible, like test ! -d on a file that has file/.../metadata stuff still returns true for instance. But the core fs, disk layout etc. are stable AFAICS, so screw politics and get the job done ; ) New features will come with mount options only, anyway. So, what do you all say? Nighty-night, Chris -- committee: too many arguments to function pgpLBbTzNzyGg.pgp Description: PGP signature
Re: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion)
On Sun, Jul 30, 2006 at 11:39:42PM +0200, Christian Trefzer wrote: > > In order to avoid having to pull the whole tree via rsync again, you > might want to grab my script from the list and adapt it to your needs. Of course, you can tar it up manually instead. Silly me, but after approx. 9h of studying, little wonder ; ) Kind regards, Chris pgpj1TrQGhCRH.pgp Description: PGP signature
Re: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion)
Hi Wil, On Sun, Jul 30, 2006 at 02:10:04PM -0700, Wil Reichert wrote: > Hmm, looks like I have a partition to re-format now. In order to avoid having to pull the whole tree via rsync again, you might want to grab my script from the list and adapt it to your needs. Kind regards, Chris pgpNAbzw9ZKq9.pgp Description: PGP signature
Re: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion)
On Sat, Jul 29, 2006 at 03:30:15PM -0500, David Masover wrote: > > Is /usr/portage still faster on Reiser4? I know it was when I switched, > but that was years ago... It is for sure. v4 is even better with fantastillions of small files than v3. uziel pgpxeVIQPVXTn.pgp Description: PGP signature
wiki entry (Was: Re: portage tree)
On Sat, Jul 22, 2006 at 11:50:24PM -0600, Hans Reiser wrote: > Thanks Christian. You can go ahead and add something to our wiki > pointing to it if you would like. This might help tide people > over until the repacker ships. I'd love to, but alas, wiki.namesys.com appears to have a serious problem at the moment. The machine (193.232.112.68) responds to ping, the http port is open but connections fail. The university's squid proxies have quite some timeout, and I repeatedly get "connection reset by peer". Google search result yields "This wiki is installed on a busy underpowered server running Reiser4." which seems like a mild understatement. How "busy" is that machine, actually? Kind regards, Chris pgpT7rfxf1ZXM.pgp Description: PGP signature
portage tree (Was: Re: reiser4 status (correction))
Hi,
The portage tree is such a fine testing object since it should be sort
of a "best case scenario" for reiser filesystems, and needs no real
backup in case of a screwup during tests.
I've been on Gentoo for years now, used reiser3 since the days when you
had to patch it into a 2.2 kernel and tried out reiser4 on my portage
tree first of all. During my comparison, reiser3 + notail resulted in
huge amounts of wasted disk space, obviously it is not very smart to use
up a whole 4k block for a file of only few bytes. reiser3 with packed
tails was a lot better, but still it was a remarkable difference from
there to reiser4, and I am only talking storage efficiency here which
directly translates to the amount of I/O necessary to get the same data
all the way to RAM and CPU. The reiser4 dev team did a great job there!
With reiser3, I made another observation wrt. fragmentation, most of
which should be alleviated by reiser4 and its delayed allocation. Over
time, doing package database updates and querying for pending updates to
the local machine became slower. Packing up everything in a tarball,
mkfs, mount with -onoatime, unpack usually fixed the "problem". Since
the performance reduction in reiser4 is a lot less (I can hardly tell if
it makes a difference before vs. after the backup/restore "repacking") I
hardly do it any more, but once in a while I still use my script
initially written for the comparison test.
Attached is the shell script I used for comparing various mount options
for ReiserFS v3 and later v4. It is capable of converting between
ext2|3, reiser3|4 and xfs, provided the target fs stores the data
efficiently enough that everything fits inside. (I had "interesting"
results when moving from reiser3 to ext3 for testing, esp. wrt. portage
tree ; )
The script falls short at handling arbitrary mount options, but may be
trivially edited to use any desired options for a single use. Reading
and understanding is recommended before feeding your viable data to it.
I hope somebody may find it useful, or at least inspiring. Any comments
appreciated!
Kind regards,
Chris
#!/bin/sh
# ! WARNING !
# As always, BE CAREFUL AND KNOW WHAT YOU DO WHEN RUNNING THIS PROGRAM!
# At best, read the code, understand what it does, and take appropriate
# precautions. Backups of valuable data are a requirement anyway, so go
# for it BEFORE you try this out!
#
#
# SYNOPSIS:
# fsconvert.sh
#
# where fstype may be any of ext[2|3], reiser[fs|4] or xfs
# and compression method is a choice of compress, gzip or bzip2.
#
#
# USE:
# This script was initially intended to re-create old reiserfs 3
# filesystems for performance reasons, and can reasonably be considered
# useful when run once every year or two for any filesystem under heavy
# read/write load. Simply give the existing filesystem type as the fstype
# argument.
#
# Though it was written for that single purpose at first, it was recently
# adapted for filesystem type migration kind of operations, as it did
# never care about the fs type in the beginning and now takes the
# destination fs type as an argument.
#
# The script REQUIRES the concerned fs to be mounted, to have an entry in
# /etc/fstab, to have no further active mountpoints in a subdirectory,
# enough free disk space in $archdir to back up data and of course the
# required tools (mkfs., tar, compression tool of choice) to do
# all the magic.
#
# Please send any comment, modification, failure report etc. to
# ctrefzer AT gmx DOT de
#
# Have fun!
# Chris
# Changelog:
#
# 2005-10-03
# Enhanced commandline interface to support multiple target file system types
# and compression methods.
# Filesystems supported so far:
# - ext2 / 3
# - reiser 3 / 4
# - xfs
#
# Compression methods which seemed appropriate:
# - none (uncompressed archive for almost no CPU load)
# - compress (quite fast even on old machines)
# - gzip (realtime on new machines, yet impressive I/O reduction)
# - bzip2 (in case of tight disk space, but takes ages wrt. the others)
### Configure here:
# where to store the archives:
archdir="${PWD}/.fsconvert"
# Sane defaults for compression levels (and guidelines): use fast gzip on
# modern CPUs where GZIP -3 gives better compression than LZW, yet still at
# realtime, whereas BZIP2 should only be used when disk space is _really_
# critical - it will take forever. LZW (compress) is advised on not-so-recent
# machines to save some I/O without slowing things down. A nifty compromise
# may be GZIP -1 on P2/P3 class machines.
export GZIP="-1"
export BZIP2="-9"
### No modifications required below here!
### Some helper functions:
function e_report {
echo -en "${1}..."
}
function e_done {
# Paranoia is good! It's all about the data...
sync
echo " Done."
}
function e_fail {
echo " FAILED!"
exit ${1}
}
function e_usage {
echo "USAGE: ${0} "
exit 1
}
if [ -z ${1} ]
then
e_usage
else
case ${1} in
Re: Reiser4 for 2.6.17 Vanilla?
On Thu, Jun 22, 2006 at 04:41:13PM +0300, Raymond A. Meijer wrote: > > The patch reiser4-for-2.6.16-4 should apply just fine, I use it myself > > on top of 2.6.17. > > The thing is, I want to use 2.6.17-ck1 as well... I'll give it a shot with > this patch and see what happens :) You might want to take a look at the -beyond patchset, which consolidates a lot of pretty stable yet far from mainline features, including reiser4, ck, suspend2, libata pata, etc. More info and source code available at http://iphitus.loudas.com/archck.php The latest version is against 2.6.16, and it might take some time before the first 2.6.17 patchset arrives since the author tends to be busy with school sometimes. Kind regards, Chris pgpqQzpI5qrjr.pgp Description: PGP signature
Re: Reiser4 for 2.6.17 Vanilla?
Hi Ray, On Thu, Jun 22, 2006 at 09:55:06AM +0300, Raymond A. Meijer wrote: > Is there a Reiser4 for the 2.6.17 Vanilla kernel yet? > > I've searched namesys.com but I couldn't find it, only Reiser4 for > 2.6-17-rc4-mm1... The patch reiser4-for-2.6.16-4 should apply just fine, I use it myself on top of 2.6.17. Kind regards, Chris pgpBzYVJe9TpA.pgp Description: PGP signature
got some "nikita-3233"s here...
Hi folks, just had this in my dmesg after git yelled at me: reiser4[git-update-inde(24210)]: extent2tail (/usr/src/sources/linux-git/fs/reiser4/plugin/file/tail_conversion.c:662)[]: WARNING: write_tail failed reiser4[git-update-inde(24210)]: release_unix_file (/usr/src/sources/linux-git/fs/reiser4/plugin/file/file.c:2260)[nikita-3233]: WARNING: Failed (-28) to convert in release_unix_file (215174) reiser4[git-unpack-file(24222)]: extent2tail (/usr/src/sources/linux-git/fs/reiser4/plugin/file/tail_conversion.c:662)[]: WARNING: write_tail failed reiser4[git-unpack-file(24222)]: release_unix_file (/usr/src/sources/linux-git/fs/reiser4/plugin/file/file.c:2260)[nikita-3233]: WARNING: Failed (-28) to convert in release_unix_file (213520) reiser4[git-update-inde(24221)]: extent2tail (/usr/src/sources/linux-git/fs/reiser4/plugin/file/tail_conversion.c:662)[]: WARNING: write_tail failed reiser4[git-update-inde(24221)]: release_unix_file (/usr/src/sources/linux-git/fs/reiser4/plugin/file/file.c:2260)[nikita-3233]: WARNING: Failed (-28) to convert in release_unix_file (215179) reiser4[git-update-inde(24232)]: extent2tail (/usr/src/sources/linux-git/fs/reiser4/plugin/file/tail_conversion.c:662)[]: WARNING: write_tail failed reiser4[git-update-inde(24232)]: release_unix_file (/usr/src/sources/linux-git/fs/reiser4/plugin/file/file.c:2260)[nikita-3233]: WARNING: Failed (-28) to convert in release_unix_file (215183) reiser4[git-update-inde(24232)]: extent2tail (/usr/src/sources/linux-git/fs/reiser4/plugin/file/tail_conversion.c:662)[]: WARNING: write_tail failed reiser4[git-update-inde(24232)]: release_unix_file (/usr/src/sources/linux-git/fs/reiser4/plugin/file/file.c:2260)[nikita-3233]: WARNING: Failed (-28) to convert in release_unix_file (215184) reiser4[git-unpack-file(24255)]: extent2tail (/usr/src/sources/linux-git/fs/reiser4/plugin/file/tail_conversion.c:662)[]: WARNING: write_tail failed reiser4[git-unpack-file(24255)]: release_unix_file (/usr/src/sources/linux-git/fs/reiser4/plugin/file/file.c:2260)[nikita-3233]: WARNING: Failed (-28) to convert in release_unix_file (213523) reiser4[git-unpack-file(24257)]: extent2tail (/usr/src/sources/linux-git/fs/reiser4/plugin/file/tail_conversion.c:662)[]: WARNING: write_tail failed reiser4[git-unpack-file(24257)]: release_unix_file (/usr/src/sources/linux-git/fs/reiser4/plugin/file/file.c:2260)[nikita-3233]: WARNING: Failed (-28) to convert in release_unix_file (121385) reiser4[git-checkout-in(24262)]: extent2tail (/usr/src/sources/linux-git/fs/reiser4/plugin/file/tail_conversion.c:714)[nikita-2282]: WARNING: Partial conversion of 121385: 3 of 4: -22 reiser4[git-checkout-in(24262)]: release_unix_file (/usr/src/sources/linux-git/fs/reiser4/plugin/file/file.c:2260)[nikita-3233]: WARNING: Failed (-22) to convert in release_unix_file (121385) reiser4[git-read-tree(24272)]: extent2tail (/usr/src/sources/linux-git/fs/reiser4/plugin/file/tail_conversion.c:714)[nikita-2282]: WARNING: Partial conversion of 213520: 3 of 4: -22 reiser4[git-read-tree(24272)]: release_unix_file (/usr/src/sources/linux-git/fs/reiser4/plugin/file/file.c:2260)[nikita-3233]: WARNING: Failed (-22) to convert in release_unix_file (213520) Next logical step was umount and fsck, which gave (with --check at first): FSCK: Directory [1d9ce:336400:22dc4]: can't find the object [1d9ce:6f626a5f77576c:34210] pointed by the entry [ce69096aa8509b067aceb38324d8ec7de0e1aa]. FSCK: Directory [1d9ce:343400:1da28]: can't find the object [1da28:13061376665:1da29] pointed by the entry [0a733fe2e9ea3d1374d4fd72e7bba60e268e05]. FSCK: Directory [1d9ce:363100:27582]: can't find the object [1d9ce:6f626a5f75494a:34213] pointed by the entry [b5b6191e22aad81fd7279878490b150a68c061]. FSCK: Directory [1d9ba:6b65726e656c00:33416]: can't find the object [33416:c6776f726b717565:3488f] pointed by the entry [workqueue.c]. and afterwards with --fix: FSCK: Directory [1d9ce:336400:22dc4]: can't find the object [1d9ce:6f626a5f77576c:34210] pointed by the entry [ce69096aa8509b067aceb38324d8ec7de0e1aa]. Entry is removed. FSCK: Directory [1d9ce:343400:1da28]: can't find the object [1da28:13061376665:1da29] pointed by the entry [0a733fe2e9ea3d1374d4fd72e7bba60e268e05]. Entry is removed. FSCK: Directory [1d9ce:363100:27582]: can't find the object [1d9ce:6f626a5f75494a:34213] pointed by the entry [b5b6191e22aad81fd7279878490b150a68c061]. Entry is removed. FSCK: Directory [1d9ba:6b65726e656c00:33416]: can't find the object [33416:c6776f726b717565:3488f] pointed by the entry [workqueue.c]. Entry is removed. Now git screws around a little, guess it is missing the four entries that have been removed. Will look further into this. Kind regards, Chris pgped9LcGT4bV.pgp Description: PGP signature
[FYI] [SOLVED] building against Linus' current git: unresolved symbol
Hi folks, the patch below is required on top of reiser4-for-2.6.16-4 to actually use reiser4 as a module with Linus' current git tree, mostly 2.6.17-rc5-git10. Otherwise the symbol "handle_ra_miss" cannot be resolved, thus the module won't be loaded. Just pointing this out, to avoid problems with early patches against 2.6.17 : ) Kind regards, Chris diff --git a/mm/readahead.c b/mm/readahead.c index 0f142a4..2494c2a 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -573,6 +573,7 @@ void handle_ra_miss(struct address_space ra->flags &= ~RA_FLAG_INCACHE; ra->cache_hit = 0; } +EXPORT_SYMBOL_GPL(handle_ra_miss); /* * Given a desired number of PAGE_CACHE_SIZE readahead pages, return a pgpI5rcqZywBt.pgp Description: PGP signature
Re: Recent patch frenzy, conflicts and Oopses
On Tue, May 16, 2006 at 02:32:20PM +0400, Alexander Zarochentsev wrote: > > The patch disables the BUG() but reiser4 can deadlock. However the > deadlock requires 3 processes to use the same EA/NEA semaphore. > > better patches are there: > > ftp.kernel.org:/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/broken-out/ > reiser4-have-get_exclusive_access-restart-transaction.patch > reiser4-add-missing-txn_restart-before-get_nonexclusive_access-calls.patch > Thanks a bunch for clarification! It seems I am not the only one on this list who got confused by bug reports and different approaches to fix those. Kind regards, Chris pgpMxi0HMbHtm.pgp Description: PGP signature
Re: [FYI]: Two compiler warnings in fs/reiser4/plugin/object.c with gcc-4.1.0
On Tue, May 16, 2006 at 01:35:24PM +0400, Vladimir V. Saveliev wrote: > > What versions of linux and reiser4 do you compile? > Oh, and reiser4 was reiser4-for-2.6.16-2 plus a few fixes: 01-reiser4-for-2.6.16-2.patch 02-reiser4-avoid-out-of-memory-question-bug.patch 03-reiser4-radix-tree-direct-data-fix.patch 04-reiser4-fix-block-alloc-assertions.patch This works reliably so far for quite some time. I might look into applying anything reiser4-related from current -mm and checking the differences in fs/reiser4 - some of the more recent reiser4 patches are related to other changes in Andrew's tree, though, and only mean to make reiser4 play along. Kind regards, Chris pgpmfrNBu16lL.pgp Description: PGP signature
Re: [FYI]: Two compiler warnings in fs/reiser4/plugin/object.c with gcc-4.1.0
On Tue, May 16, 2006 at 01:35:24PM +0400, Vladimir V. Saveliev wrote: > Hello > > On Mon, 2006-05-15 at 16:53 +0200, Christian Trefzer wrote: > > fs/reiser4/plugin/object.c:120: Warnung: Initialisierung von inkompatiblem > > Zeigertyp > > fs/reiser4/plugin/object.c:320: Warnung: Initialisierung von inkompatiblem > > Zeigertyp > > > > (in english: Warning: initialization from incompatible pointer type) > > > > What versions of linux and reiser4 do you compile? > That would be current git, which is mostly 2.6.17-rc4, with reiser4 on top. Kind regards, Chris pgpYM66AXZ2WW.pgp Description: PGP signature
[FYI]: Two compiler warnings in fs/reiser4/plugin/object.c with gcc-4.1.0
fs/reiser4/plugin/object.c:120: Warnung: Initialisierung von inkompatiblem
Zeigertyp
fs/reiser4/plugin/object.c:320: Warnung: Initialisierung von inkompatiblem
Zeigertyp
(in english: Warning: initialization from incompatible pointer type)
file_plugin file_plugins[LAST_FILE_PLUGIN_ID] = {
[UNIX_FILE_PLUGIN_ID] = {
.as_ops = {
.writepage = reiser4_writepage,
.readpage = readpage_unix_file,
.sync_page = block_sync_page,
.writepages = writepages_unix_file,
.set_page_dirty = reiser4_set_page_dirty,
.readpages = reiser4_readpages,
.prepare_write = prepare_write_unix_file,
.commit_write = commit_write_unix_file,
.bmap = bmap_unix_file,
120:.invalidatepage = reiser4_invalidatepage,
.releasepage = reiser4_releasepage
},
[CRC_FILE_PLUGIN_ID] = {
.as_ops = {
.writepage = reiser4_writepage,
.readpage = readpage_cryptcompress,
.sync_page = block_sync_page,
.writepages = writepages_cryptcompress,
.set_page_dirty = reiser4_set_page_dirty,
.readpages = reiser4_readpages,
.prepare_write = prepare_write_common,
320:.invalidatepage = reiser4_invalidatepage,
.releasepage = reiser4_releasepage
},
Another warning mentions _possibly_ uninitialized use of a variable:
fs/reiser4/plugin/space/bitmap.c: In Funktion »load_and_lock_bnode«:
fs/reiser4/plugin/space/bitmap.c:817: Warnung: »cjnode« könnte in dieser
Funktion uninitialisiert verwendet werden
(»cjnode« could be used uninitialized in this function)
Kind regards,
Chris
pgp11PxO6ukwa.pgp
Description: PGP signature
Recent patch frenzy, conflicts and Oopses
Hi guys,
as I am heavily using reiser4 for some time now on my stable machine, I
keep a git tree with vanilla -stable and reiser4 since -mm has sometimes
been too unreliable. Lurking on this list I collected some patches, of
which two seem to collide. The first one fixes a nasty "out of memory?"
Oops for me and maybe others, and the second one was posted as a
response to other Oopses on the list.
Since I reversed the first one in order to apply the second one,
thinking (wrongly) that this one should be a better fix for the same issues and
maybe more, I have my old pal out of memory back. Maybe the two should
be merged in a compatible way, and a new patch against 2.6.16-stable be
put on the namesys ftp server?
Anyway, here come the patches in question:
From: Alexander Zarochentsev <[EMAIL PROTECTED]>
To: reiserfs-list@namesys.com
Subject: Re: "warning("vs-44", "out of memory?")"
Date: Wed, 12 Apr 2006 14:26:59 +0400
On Wednesday 12 April 2006 13:06, Alexander Zarochentsev wrote:
> Hello
>
> On Wednesday 12 April 2006 11:42, Roy Lanek wrote:
> > I have managed to save a copy of my
> > /var/log/socklog-klog/others/current
> > before the next complete freezing happened.
>
> Please use the latest reiser4 patch reiser4-for-2.6.16-2 from
> ftp.namesys.com.
and apply the following patch:
Index: linux-2.6.17-rc1-mm1/fs/reiser4/plugin/item/extent_file_ops.c
===
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/plugin/item/extent_file_ops.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/plugin/item/extent_file_ops.c
@@ -807,7 +807,7 @@ extent_balance_dirty_pages(struct inode
if (excl)
get_exclusive_access(uf_info);
else
- get_nonexclusive_access(uf_info, 0);
+ get_nonexclusive_access(uf_info, 1);
}
return 0;
}
Index: linux-2.6.17-rc1-mm1/fs/reiser4/plugin/item/tail.c
===
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/plugin/item/tail.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/plugin/item/tail.c
@@ -510,7 +510,7 @@ tail_balance_dirty_pages(struct address_
if (excl)
get_exclusive_access(uf_info);
else
- get_nonexclusive_access(uf_info, 0);
+ get_nonexclusive_access(uf_info, 1);
}
return 0;
}
This one helped me a lot. The second one brought older problems back,
but may have fixed others for some people on this list. It seems to
remove the second argument to get_nonexclusive_access(), though:
From: Alexander Zarochentsev <[EMAIL PROTECTED]>
To: reiserfs-list@namesys.com
Subject: Re: Reproducible reiser4 bug with 2.6.16.2 patch on
tail_conversion.c:80
Date: Thu, 11 May 2006 11:24:53 +0400
--Boundary-00=_FbuYEKWWhFAJ/IU
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hello
[original message snipped]
please check whether the attached patch helps.
--
Alex.
--Boundary-00=_FbuYEKWWhFAJ/IU
Content-Type: text/x-diff;
charset="iso-8859-1";
name="reiser4-remove-atom_may_exists-from-get_nea.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="reiser4-remove-atom_may_exists-from-get_nea.diff"
fs/reiser4/plugin/file/file.c| 17 -
fs/reiser4/plugin/file/file.h|2 +-
fs/reiser4/plugin/file/funcs.h |5 -
fs/reiser4/plugin/file/tail_conversion.c | 12 +++-
fs/reiser4/plugin/item/extent_file_ops.c |3 ++-
fs/reiser4/plugin/item/tail.c|3 ++-
6 files changed, 16 insertions(+), 26 deletions(-)
Index: linux-2.6.17-rc3-mm1/fs/reiser4/plugin/item/extent_file_ops.c
===
--- linux-2.6.17-rc3-mm1.orig/fs/reiser4/plugin/item/extent_file_ops.c
+++ linux-2.6.17-rc3-mm1/fs/reiser4/plugin/item/extent_file_ops.c
@@ -804,10 +804,11 @@ extent_balance_dirty_pages(struct inode
f->length > PAGE_CACHE_SIZE ?
PAGE_CACHE_SIZE : f->length);
+ txn_restart_current();
if (excl)
get_exclusive_access(uf_info);
else
- get_nonexclusive_access(uf_info, 0);
+ get_nonexclusive_access(uf_info);
}
return 0;
}
Index: linux-2.6.17-rc3-mm1/fs/reiser4/plugin/item/tail.c
===
--- linux-2.6.17-rc3-mm1.orig/fs/reiser4/plugin/item/tail.c
+++ linux-2.6.17-rc3-mm1/fs/reiser4/plugin/item/tail.c
@@ -507,10 +507,11 @@ tail_balance_dirty_pages(struct address_
} else
drop_nonexclusive_access(uf_info);
reiser4_throttle_write(inode);
+ txn_restart_curren
Re: kernel BUG at /usr/src/sources/linux-2.6.16-rc5/fs/reiser4/plugin/file/tail_conversion.c:29
Hi zam,
On Wed, Mar 15, 2006 at 11:11:49AM +0300, Alexander Zarochentsev wrote:
> Hello,
>
> please try the attached patch.
>
> --
> Alex.
> [ skipped life-saving patch ]
I just checked my currently used reiser4 version against
reiser4-for-2.6.16-1 and noticed that this patch was not in there. The
diff between my copy (2.6.16-rc4-mm2 with your patch on top) and status
quo follows:
diff -urN a/fs/reiser4/as_ops.c b/fs/reiser4/as_ops.c
--- a/fs/reiser4/as_ops.c 2006-03-20 20:11:38.0 +0100
+++ b/fs/reiser4/as_ops.c 2006-03-30 14:19:27.0 +0200
@@ -222,7 +222,7 @@
ctx = init_context(inode->i_sb);
if (IS_ERR(ctx))
- return PTR_ERR(ctx);
+ return RETERR(PTR_ERR(ctx));
node = jprivate(page);
spin_lock_jnode(node);
diff -urN a/fs/reiser4/page_cache.c b/fs/reiser4/page_cache.c
--- a/fs/reiser4/page_cache.c 2006-03-20 20:11:38.0 +0100
+++ b/fs/reiser4/page_cache.c 2006-03-30 14:19:27.0 +0200
@@ -198,10 +198,6 @@
{
assert("nikita-2168", fake->i_state & I_NEW);
fake->i_mapping->a_ops = &formatted_fake_as_ops;
- fake->i_blkbits = super->s_blocksize_bits;
- fake->i_size = ~0ull;
- fake->i_rdev = super->s_bdev->bd_dev;
- fake->i_bdev = super->s_bdev;
*pfake = fake;
/* NOTE-NIKITA something else? */
unlock_new_inode(fake);
diff -urN a/fs/reiser4/plugin/file/file.c b/fs/reiser4/plugin/file/file.c
--- a/fs/reiser4/plugin/file/file.c 2006-03-20 20:11:38.0 +0100
+++ b/fs/reiser4/plugin/file/file.c 2006-03-30 14:19:27.0 +0200
@@ -1451,6 +1451,9 @@
int result;
unix_file_info_t *uf_info;
+ /* close current transaction */
+ txn_restart_current();
+
uf_info = unix_file_inode_data(inode);
/*
@@ -2171,6 +2174,7 @@
done_lh(&hint->lh);
if (!exclusive) {
drop_nonexclusive_access(uf_info);
+ txn_restart_current();
get_exclusive_access(uf_info);
}
result = tail2extent(uf_info);
@@ -2960,6 +2964,15 @@
unix_file_info_t *uf_info;
int result;
+ /*
+* transaction can be open already. For example:
+* writeback_inodes->sync_sb_inodes->reiser4_sync_inodes->
+* generic_sync_sb_inodes->iput->generic_drop_inode->
+* generic_delete_inode->reiser4_delete_inode->delete_object_unix_file.
+* So, restart transaction to avoid deadlock with file rw semaphore.
+*/
+ txn_restart_current();
+
if (inode_get_flag(inode, REISER4_NO_SD))
return 0;
diff -urN a/fs/reiser4/plugin/file/tail_conversion.c
b/fs/reiser4/plugin/file/tail_conversion.c
--- a/fs/reiser4/plugin/file/tail_conversion.c 2006-03-20 20:11:38.0
+0100
+++ b/fs/reiser4/plugin/file/tail_conversion.c 2006-03-30 14:19:27.0
+0200
@@ -20,12 +20,13 @@
assert("nikita-3047", LOCK_CNT_NIL(inode_sem_w));
assert("nikita-3048", LOCK_CNT_NIL(inode_sem_r));
/*
-* "deadlock avoidance": sometimes we commit a transaction under
+* "deadlock detection": sometimes we commit a transaction under
* rw-semaphore on a file. Such commit can deadlock with another
* thread that captured some block (hence preventing atom from being
* committed) and waits on rw-semaphore.
*/
- txn_restart_current();
+ assert("nikita-3361", get_current_context()->trans->atom == NULL);
+ BUG_ON(get_current_context()->trans->atom != NULL);
LOCK_CNT_INC(inode_sem_w);
down_write(&uf_info->latch);
uf_info->exclusive_use = 1;
This would basically revert your patch once applied to my local copy,
and make some other tiny changes. Will those take care of the problem,
or was your solution lost somehow?
The diff between reiser4-for-2.6.16-1 with your patch applied and my copy looks
like this:
diff -urN a/fs/reiser4/as_ops.c b/fs/reiser4/as_ops.c
--- a/fs/reiser4/as_ops.c 2006-03-20 20:11:38.0 +0100
+++ b/fs/reiser4/as_ops.c 2006-03-30 14:19:27.0 +0200
@@ -222,7 +222,7 @@
ctx = init_context(inode->i_sb);
if (IS_ERR(ctx))
- return PTR_ERR(ctx);
+ return RETERR(PTR_ERR(ctx));
node = jprivate(page);
spin_lock_jnode(node);
diff -urN a/fs/reiser4/page_cache.c b/fs/reiser4/page_cache.c
--- a/fs/reiser4/page_cache.c 2006-03-20 20:11:38.0 +0100
+++ b/fs/reiser4/page_cache.c 2006-03-30 14:19:27.0 +0200
@@ -198,10 +198,6 @@
{
assert("nikita-2168", fake->i_state & I_NEW);
fake->i_mapping->a_ops = &formatted_fake_as_ops;
- fake->i_blkbits = super->s_blocksize_bits;
- fake->i_size = ~0ull;
-
Re: kernel BUG at /usr/src/sources/linux-2.6.16-rc5/fs/reiser4/plugin/file/tail_conversion.c:29
On Thu, Mar 16, 2006 at 08:35:01PM +0300, Alexander Zarochentsev wrote: > I looked one more time at my second patch and realized now that is it > not needed, it solves problem which can't happen. I was thinking too > much trying to invent a situation where the first patch fails :) Well, so I'll leave the first one applied instead, presuming that this is the one you will merge into "mainstream" reiser4 code? Thanks, Chris pgpZKwX2ntl6c.pgp Description: PGP signature
Re: kernel BUG at /usr/src/sources/linux-2.6.16-rc5/fs/reiser4/plugin/file/tail_conversion.c:29
Hi zam, On Thu, Mar 16, 2006 at 10:28:37AM +0300, Alexander Zarochentsev wrote: > > I guess it was in release_unix_file where get_exclusive_access is called > outside reiser4_context. > > can you please replace the old patch by the attached one? Sure I can, but so far I did not have any further trouble after applying your first patch. It seems to me that exchanging the two patches won't bring the BUG back, so I will report in a few days with something along the lines of "thank you very much". You will, on the other hand, definitely hear from me if the thing BUGs on me again ; ) Thanks for your time! Chris pgp3ntxBv9xqv.pgp Description: PGP signature
Re: kernel BUG at /usr/src/sources/linux-2.6.16-rc5/fs/reiser4/plugin/file/tail_conversion.c:29
Hi zam, after the first build of OOo has finished (as "gift" for my laptop) the machine is working on it's own copy, after a reboot with the exact same setup yielding my BUG problems plus your patch applied. I'll keep an eye on my syslog. Sorry for taking so long! Regards, Chris pgpzVAOAAJdik.pgp Description: PGP signature
Re: kernel BUG at /usr/src/sources/linux-2.6.16-rc5/fs/reiser4/plugin/file/tail_conversion.c:29
Hi again, small update and clarification: I wiped the laptop's volume on which the problem occured, but my workstation's has _not yet_ been wiped. But: kernel BUG at /usr/src/sources/linux-2.6.16-rc5/fs/reiser4/plugin/file/tail_conversion.c:29! invalid opcode: [#1] PREEMPT Modules linked in: mga drm usb_storage libusual w83781d hwmon_vid hwmon i2c_isa snd_seq_midi snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_cmipci snd_opl3_lib snd_hwdep snd_mpu401_uart ohci_hcd floppy sr_mod cdrom pata_via i2c_viapro aic7xxx scsi_transport_spi ehci_hcd uhci_hcd 3c59x mii snd_ens1370 gameport snd_rawmidi snd_seq_device snd_pcm snd_timer snd_ak4531_codec snd soundcore snd_page_alloc via_agp agpgart usbcore xfs exportfs reiser4 ext2 loop lp parport_pc parport rtc psmouse reiserfs dm_mod raid5 raid1 xor md_mod pata_pdc2027x libata sd_mod scsi_mod unix CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010282 (2.6.16-rc5 #10) EIP is at get_exclusive_access+0x31/0x44 [reiser4] eax: bdb66604 ebx: ecx: d44cd294 edx: d09041e0 esi: 3d762000 edi: 6c85 ebp: 6c85 esp: c33c9f0c ds: 007b es: 007b ss: 0068 Process soffice.bin (pid: 687, threadinfo=c33c9000 task=cfc0da90) Stack: <0>f2da83da e6578e8c d2f12ee8 7000 b014c75f e6578e8c b19e8900 b0151cd1 d025fda8 d025fd9c 3d762000 c1465440 b7c775c0 bdb665c0 d44cd2ec d44cd294 6c85 0001 d44cd2a0 6c85 Call Trace: [] write_unix_file+0x1ba/0x60c [reiser4] [] write_unix_file+0x0/0x60c [reiser4] [] syscall_call+0x7/0xb Code: ff 21 e0 8b 00 8b 80 b0 04 00 00 8b 40 40 8b 50 08 85 d2 75 16 ba 01 00 ff ff 89 c8 0f c1 10 85 d2 75 12 c7 41 24 01 00 00 00 c3 <0f> 0b 1d 00 04 8c dc f2 eb e0 51 e8 13 ac 35 bd 59 eb e5 55 89 <6>lp0: ECP mode This is what I got with the laptop's disk in a USB case and the home volume from there mounted as /home. Processes stuck in D state were all trying to write to /home. I have to mention that the volume on the laptop disk which had problems before was _not_ home, so this is not a repetition of something I've seen before. Basically, I have now reset my sysctl values regarding the vm subsystem to the default values and will try to reproduce. Workstation has 1GB of RAM and is trying to build OOo2 from source at the time, but writing the build tree to a totally different volume. The build process also is not interrupted by this BUG. Thanks, Chris pgpsJS6vH1G57.pgp Description: PGP signature
Re: kernel BUG at /usr/src/sources/linux-2.6.16-rc5/fs/reiser4/plugin/file/tail_conversion.c:29
Hi Alexander, On Wed, Mar 15, 2006 at 11:11:49AM +0300, Alexander Zarochentsev wrote: > please try the attached patch. Wow, that was FAST! Will do ASAP, but for now I'll have to _hurry_ to work. I'll build a kernel with your patch right when I come back. Thanks a bunch! Chris pgpTE8mCvAmrh.pgp Description: PGP signature
kernel BUG at /usr/src/sources/linux-2.6.16-rc5/fs/reiser4/plugin/file/tail_conversion.c:29
Hi everyone, I got this half an hour ago, with some processes left in D state, namely ooffice.bin and two instances of procmail, as this happened on my /home LV: kernel BUG at /usr/src/sources/linux-2.6.16-rc5/fs/reiser4/plugin/file/tail_conversion.c:29! invalid opcode: [#1] PREEMPT Modules linked in: mga drm w83781d hwmon_vid hwmon i2c_isa snd_seq_midi snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_cmipci snd_opl3_lib snd_hwdep snd_mpu401_uart ohci_hcd floppy sr_mod cdrom pata_via i2c_viapro aic7xxx scsi_transport_spi ehci_hcd uhci_hcd 3c59x mii snd_ens1370 gameport snd_rawmidi snd_seq_device snd_pcm snd_timer snd_ak4531_codec snd soundcore snd_page_alloc via_agp agpgart usbcore xfs exportfs reiser4 ext2 loop lp parport_pc parport rtc psmouse reiserfs dm_mod raid5 raid1 xor md_mod pata_pdc2027x libata sd_mod scsi_mod unix CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.16-rc5 #10) EIP is at get_exclusive_access+0x31/0x44 [reiser4] eax: b26d6c04 ebx: ecx: ec54bbf4 edx: b736fdc0 esi: 3dbf3000 edi: 6c85 ebp: 6c85 esp: ded36f0c ds: 007b es: 007b ss: 0068 Process soffice.bin (pid: 12533, threadinfo=ded36000 task=b3b7b070) Stack: <0>f2da83da c52ca544 e52935a8 7000 b014c75f c52ca544 e7b3cc80 b0151cd1 b6b54354 b6b5434c 3dbf3000 ed113360 e6a02160 b26d6bc0 ec54bc4c ec54bbf4 6c85 0001 ec54bc00 6c85 Call Trace: [] write_unix_file+0x1ba/0x60c [reiser4] [] write_unix_file+0x0/0x60c [reiser4] [] syscall_call+0x7/0xb Code: ff 21 e0 8b 00 8b 80 b0 04 00 00 8b 40 40 8b 50 08 85 d2 75 16 ba 01 00 ff ff 89 c8 0f c1 10 85 d2 75 12 c7 41 24 01 00 00 00 c3 <0f> 0b 1d 00 04 8c dc f2 eb e0 51 e8 13 ac 35 bd 59 eb e5 55 89 I had another occurrence of something looking similar at first glance, repeatedly grinding my laptop to halt when I was on a trip. The only way to make it go away was to wipe the device by dd'ing /dev/zero to it. Not even tar-backup and mkfs did the job - otherwise I could have left out the word "repeatedly"... The only thing I could imagine other than a serious problem wrt. reiser4 code is a "soft" bad block relocated by the drive upon write, but there was nothing like a read error in the logs. Furthermore I wanted the gurus to know since it occured to me more than once. Thanks for your time! Chris FYI, here comes something about the disk, including SMART error log: /dev/sda: ATA device, with non-removable media Model Number: SAMSUNG SV1203N Serial Number: S01CJ10Y410901 Firmware Revision: TQ100-30 Standards: Supported: 7 6 5 4 Likely used: 7 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 234493056 LBA48 user addressable sectors: 234493056 device size with M = 1024*1024: 114498 MBytes device size with M = 1000*1000: 120060 MBytes (120 GB) Capabilities: LBA, IORDY(can be disabled) Queue depth: 1 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 254, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=240ns IORDY flow control=120ns Commands/features: Enabled Supported: *READ BUFFER cmd *WRITE BUFFER cmd *Host Protected Area feature set *Look-ahead *Write cache *Power Management feature set Security Mode feature set *SMART feature set *FLUSH CACHE EXT command *Mandatory FLUSH CACHE command *Device Configuration Overlay feature set *48-bit Address feature set *Automatic Acoustic Management feature set SET MAX security extension *DOWNLOAD MICROCODE cmd *SMART self-test *SMART error logging Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count supported: enhanced erase 56min for SECURITY ERASE UNIT. 56min for ENHANCED SECURITY ERASE UNIT. HW reset results: CBLID- above Vih Device num = 0 determined by the jumper Checksum: correct smartctl version 5.33 [i386-pc-linux-gnu] Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ ===
Re: -mm -> 2.6.13 merge status
Hans Reiser schrieb: Christian Trefzer wrote: Hubert Chan schrieb: How about something of the form "nikita-955(file:line)"? Or the reverse: "file:line(nikita-955)". Would that keep everyone happy? Makes me happy. Nice, how about the others? Hey, if we need some objective and neutral mediators on lkml, I'd be glad to give my reading frenzies a meaning : ) signature.asc Description: OpenPGP digital signature
Re: -mm -> 2.6.13 merge status
Hubert Chan schrieb: How about something of the form "nikita-955(file:line)"? Or the reverse: "file:line(nikita-955)". Would that keep everyone happy? Damn, I was wondering how long it would take until someone would come up with a compromise solution ; ) Compromises everywhere will lead to nowhere, I've learned that the hard way. But this is really not a major issue, so let's not make a showstopper out of this one and the likes. For what I know about the whole inclusion discussion until now, there's been a whole lot of flamewar chickenshit so far. Considering that I have no FS developing abilities whatsoever, I'm pretty pissed at people who do know better in their field and should know better than waste their time on discussions other than constructive ones. Get the personal bullshit out of the way, everyone, please! Get in touch and work out your differences in a productive manner. If every interesting yet at first intrusive extension to the kernel causes as much kindergarten as this one, where will we end up? Stagnation sucks, yet good progress is sometimes slow-paced... Peace, everyone! Chris (hardcore, not hippie) signature.asc Description: OpenPGP digital signature
