I can only boot in maintenence mode when I got this version emerged. My quick fix for now is just to unmerge reiserfsprogs, but with this version I cannot check my filesystem. I think it was in the last weekend I got hit by this bug...maybe it has something to do with the fix between 3.6.12 & 3.6.12-r1?? My device is quite big (229G) Reproducible: Always Steps to Reproduce: 1.reiserfsck "my reiserfs device" 2. 3. Actual Results: reiserfsck aborting with this message "count_blocks: block device too large" Expected Results: Said that my filesystem was ok emerge info Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040207-r0, 2.4.23) ================================================================= System uname: 2.4.23 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.4.3.13 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=pentium4 -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -mcpu=pentium4 -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://ftp.gentoo.skynet.be/pub/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/gnome-current" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X Xaw3d aalib acl acpi adns alsa apache2 apm avi berkdb bindist bonobo cdr crypt cscope cups curl dedicated dga directfb divx doc dvb dvd dvdr emacs emacs-w3 encode esd ethereal evo faad fam fbcon firebird flac flash foomaticdb freetds gb gd gdbm ggi gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml imap imlib innodb ipv6 jabber jack java jikes joystick jpeg kde kerberos ladcca lcms ldap leim libg++ libgda libwww lirc mad maildir mbox mcal memlimit mikmod mmx motif mozilla mpeg msn mule mysql nas ncurses nls oci8 odbc oggvorbis opengl oscar oss pam pda pdflib perl plotutils png postgres ppds python quicktime readline ruby samba sasl scanner sdl slang slp socks5 speex spell sqlite sse ssl svga tcltk tcpd tetex tiff truetype unicode usb videos wmf wxwindows x86 xface xinerama xml xml2 xmms xosd xv xvid zlib"
Ahh I have forgot to mention, that the same problem exists with 3.6.13 :-)
And the bug is also existing in 3.6.17
weird, i have no problems with my raids ... one is ~400G and the other is ~320G ...
Same Problem here. 360 GB Raid 5 Array on a SX4000.
I had the same problem, and pestering someone in #gentoo-dev, I got help from blackace who suggested trying the blk_size.patch. It worked like a charm. This problem can be temporarily fixed by editing the ebuild for 3.6.11-r1. As a temporary hack, change references to ia64 to x86 in the keywords and first IF statement, and specify that specific ebuild: emerge =sys-fs/reiserfsprogs-3.6.11-r1 This builds OK on x86 w/gcc 3.3.4-r1, and the resulting reiserfsck will successfully run. I have a 360GB RAID-5 array on a Promise S150 SATA raid controller, using Promise's "b24" driver (which is I -think- also used for the SX4000- same card as someone else in this bug is using; I believe the S150 just contains SATA interfaces, all the other guts are the same). The array has a single partition inside an extended partition- and is the full size of the array, with approx 85-90GB free. Someone should confirm this issue with the ReiserFS team (which did not answer an email on Friday night from me, not especially surprising) and also confirm the patch is good for 3.6.17, the current release- and make a -r1 ebuild with the patch included until Reiser releases a fixed version.
they've integrated this patch with reiserfsprogs-3.6.18 which is now in portage
emerged reiserfsprogs-3.6.18 but still have the same problem (device too large) i'm using the ft3xx driver for my promise TX4000 the partition (150GB) has about 90% Use (i think that's no too much for reiserFS) # cat /proc/scsi/ft3xx/1 PROMISE FastTrak TX4000/376/378/S150 TX Series Linux Driver Version 1.00.0.19 Adapter1 - FastTrak TX4000 Array - Array[1] : 1X2 Mirror (OK-Gigabyte Boundary) Drive - 1 : SAMSUNG SP1604N IDE1/Master 160041MB IRQ( 7) UDMA5 Array[1] 3 : SAMSUNG SP1604N IDE2/Master 160041MB IRQ( 7) UDMA5 Array[1] any suggestions? (i have not tried to patch the ebuild because i believe it's already in the 3.6.18 revision)
Yes. The problem hasn't been solved for me either. Could it have something to do about which block size/ stripe size is used for creating the raid? If the size is small...maybe reiserfs doesn't handle that well?
the reiserfs devs are aware of this and fixes should be sought with them ... here is the last e-mail i received from them: From: Vitaly Fertman <vitaly@namesys.com> (NAMESYS) Hi, the problem is somewhere in incorrect definishion of BLKGETSIZE64. reiserfsprogs check if it is defined in the system headers and if not define it as: #if defined(__linux__) && defined(_IOR) && !defined(BLKGETSIZE64) # define BLKGETSIZE64 _IOR(0x12, 114, __u64) #endif Last investigations have shown that the correct definition should be #if defined(__linux__) && defined(_IOR) && !defined(BLKGETSIZE64) # define BLKGETSIZE64 _IOR(0x12, 114, size_t) #endif (the patch is attached). To figure out where the problem is, the following is needed: - try the patch, check if the problem exists; - if exists, remove this definision from reiserfsprogs at all, check if the problem exists. - if exists, the problem is likely to be in the system headers that define BLKGETSIZE64 differently from the kernel. report me about the result please.
Ok. Thanks. Could you please attach the patch, I can then try it and report if it works?
Created attachment 39433 [details, diff] reiserfsprogs_getblksize64.patch whoops, sorry about that, here it is
I can confirm that this patch solves the problem I had
so e-mail Vitaly Fertman <vitaly@namesys.com> with your results please :)
