Re: [reiserfs-list] Boot failure: msdos pushes in front of reiserfs
Hello! On Tue, Jan 15, 2002 at 07:53:16PM +0100, Hubert Mantel wrote: > > initrd, and thus at the bottom of the list. Strange enough SuSE compile > > MSDOS which hardly anyone needs at boot time into the kernel, but not > > reiserfs (admittedly, reiserfs takes up some memory, but then, it's a > FAT is needed in order to access some modules floppy disk at installation > time. Due to space reasons, our initrd also is using FAT format now. Why not use cramfs? It would generate smaller initrd, because it compresses files. > You need _some_ filesystem in the kernel. We chose the one that needs > least space and allows people to easily put additional modules onto some vfat9872 0 (unused) fat32000 0 [vfat] cramfs 37424 0 (unused) So it is 41k for vfat, or 37k for cramfs. crams if more space-efficient. > floppy (some people have problems mounting an ext2/minix floppy under > Windows or DOS). There is no problems in loading vfat from e.g. initrd. And then to ask people to insert "additional driver disk" which would hold FAT fs on it. RedHat use minix for initrd, AFAIK. And minix fs support contains less code, too: minix 21616 0 (unused) > > Had they left MSDOS as a module, things would have worked out: 1. ext2 > > in the kernel 2. initrd loads reiserfs 3. actual root (reiserfs) is > > mounted 4. only now, msdos.o becomes available. > And which format should we use for the modules disk and for the initrd? We I believe cramfs is much better than vfat for you. > used to have ext2 in the past. It caused problems for other people. Which problems? Bye, Oleg
Re: [reiserfs-list] Boot failure: msdos pushes in front of reiserfs
Hello! On Tue, Jan 15, 2002 at 06:47:12PM +0100, Matthias Andree wrote: > > Looking at init/main.c and fs/super.c, rootfsflags parameter is never > > saved, moreover - it's original value is destroyed, once initrd fs is > > mounted. And I only see not very nice ways of fixing this, so perhaps > > someone more exeprienced can come up with the solution? (my crappy > > ides is not to do putname() on fs_names, if (real_root_dev != > > ROOT_DEV), all of this is only when CONFIG_..._INITRD enabled) > Thanks for confirming a bug, so I understand that mounting an initrd > loses the rootfsflags, and as the actual root= parameter is kept over an > initrd boot, it should also be possible for rootfsflags= -- can the > rootfsflags maybe be saved along with the root= parameter? No. rootfsflags is saved. What is not saved is rootfstype. And yes, it can be saved, of course. > > > Yup, reiserfs is last in /proc/filesystems when loaded as module, but on > > > my private machine (where it's linked into the kernel), it's right after > > > ext2 and before vfat. > > Do you have vfat as a loadable module? > Hum, yes, but that's not the point, someone turned up with a SuSE 7.3 This is the point in fact. If you'd have both reiserfs and vfat compiled-in, you'd see that vfat ebfore reiserfs in /proc/filesystems. Bye, Oleg
Re: [reiserfs-list] Tail compression
On Wed, 16 Jan 2002 19:22:58 GMT, toad said: > If you're cpu-bound, you probably don't want to compress anything, > unless a smaller tail is a lot easier to pack, which the reiserfs docs > seem to suggest... possibly this won't gain you enough to offset the > cost of compression though. Benchmarking could be interesting. > For example, if you have lots of small, compressible files and good > read locality, read performance could benefit from compression. Actually, I've found that it can be a performance win. I've benched the AIX scheme, and found that if your data is mostly-text (and thus compresses very well), it can often be faster to read 3 512-byte blocks and decompress it to a 4K logical block than to actually read 4K off the disk. This was even with SCSI-1 and a slow (by today's standards) CPU. With SCSI-2 and a 166mz 604E, the CPU overhead was still only about 1%, and disk throughput was higher by a good 15%. I suspect that for IDE/ATA, with its historically higher CPU cost for I/O, it would be even bigger a win. > OTOH, it could function as a building block for 'real compression' - a > directory with an inode flag appears as a file, contains a series of > small files with numbered names (or ideally without names, write the > hash directly); each file is a compressed 4kb block (ordinarily this > would not be stored as a tail, but here it is, after compression). > This stuff probably gains greatly from a repacker and allocate on > flush, and would also be cleaner with v4's plugins. What AIX does is compress each 4K block, and then allocate only as many 512-byte fragments as are actually needed. Another idea I've seen is the AIX/370 filesystem, which supported "small files in inode" - if the total file data was under , it wouldn't allocate any disk blocks, but use the space in the inode for the actual data. It's the equivalent of the (struct ext2_inode)->i_block[] array. Only 64 bytes or so, but it's amazing how often it saved allocating a 4K block. Probably not worth doing if you have a sane tail or fragment storage scheme, however... /Valdis msg04056/pgp0.pgp Description: PGP signature
[reiserfs-list] transient hard drive error causing problems
Below is the relevant portion of my dmesg output. I get a status error on my
first hard drive (it's a transient thing after a hard reset).
There are a few issues here:
The dmesg output does not tell me which partition the error refers to! I can
presume that it's related to the error on hda, but as hda has parts of
several RAID devices even that doesn't narrow it down much.
Can the /proc/reiserfs stuff be used to track this down?
Also there's the usual issue of messages having codes "vs-number", is there a
reference to what the numbers mean?
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hda: drive not ready for command
is_tree_node: node level 759 does not match to the expected one 2
vs-5150: search_by_key: invalid format found in block 16618. Fsck?
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data
of [13396 11199 0x0 SD]
hdb: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
is_tree_node: node level 759 does not match to the expected one 2
vs-5150: search_by_key: invalid format found in block 16618. Fsck?
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data
of [13721 31689 0x0 SD]
is_tree_node: node level 759 does not match to the expected one 2
vs-5150: search_by_key: invalid format found in block 16618. Fsck?
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data
of [13396 14810 0x0 SD]
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Re: [reiserfs-list] Tail compression
On Wed, Jan 16, 2002 at 02:05:10PM -0500, [EMAIL PROTECTED] wrote: > AIX already supports this sort of compression. Interestingly enough, > they use LZ compression instead, probably for the following reasons: liblzf.plan9.de - fast, free, primitive, or somesuch lzf should be patent-free, very small (code) and lends itself to very efficient implementations. it far from gzip's compression ratio, but vastly easier to use in kernel etc. and might come for free (Although I guess not in the reiserfs code). > something that does a reasonable job for "very short" runs. > 'gzip < /dev/null | wc' says 20 characters of overhead - do LZ or other > schemes do better? Any scheme can be coded with at most one bit overhead - the 20 bytes are file time, name and other info that only gzip encodes. tghe actual overhead is a few bytes only. > Also, think about the startup CPU cost for each > tail on compression/decompression - is gzip optimal or are other things > better? gzip is suboptimal. lzf and variants don't even need to initialize their hash table (although compression ratio is not deterministic in that case ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: [reiserfs-list] Tail compression
On Wed, Jan 16, 2002 at 02:05:10PM -0500, [EMAIL PROTECTED] wrote: > On Wed, 16 Jan 2002 15:22:45 GMT, toad <[EMAIL PROTECTED]> said: > > > Hi. Reiserfs packs small files well, and has problems with large tails. > > So would it make sense to try to gzip tails before packing? > > AIX already supports this sort of compression. Interestingly enough, > they use LZ compression instead, probably for the following reasons: > > 1) Consider any patent issues - I think LZW has a problem here. gzip > I believe is free, but... gzip is free. It's LZ77 that has patent issues, and was used in GIF, AFAIR. > > 2) Remember that you're only compressing a *tail* - as such, you want > something that does a reasonable job for "very short" runs. > 'gzip < /dev/null | wc' says 20 characters of overhead - do LZ or other > schemes do better? Also, think about the startup CPU cost for each > tail on compression/decompression - is gzip optimal or are other things > better? Right, which is why you need to only write compressed data if compression actually gains you space. gzip can actually give quite good compression on small files, judging by the output of this script: (find / -size -4k -and -type f -and -size +1k | (while read x; do echo -n `ls -l "$x" | tr --squeeze " " | cut -d " " -f 5`; echo -n " "; cp -f "$x" 1.blah; rm -f 1.blah.gz; gzip -9 1.blah; echo -n `ls -l 1.blah.gz | tr --squeeze " " | cut -d " " -f 5` " "; echo "$x"; done) | less) (results are more varied for <1kb, and it doesn't matter as much). > > Remember - this has different trade-offs than the usual usage of gzip. > Usually, you don't bother gzipping unless the file is large, and you don't > do it often, so you can afford to be slower to get better compression. > For tails, you probably want an algorithm that's 15% faster, even if the > result is 15% longer... If you're cpu-bound, you probably don't want to compress anything, unless a smaller tail is a lot easier to pack, which the reiserfs docs seem to suggest... possibly this won't gain you enough to offset the cost of compression though. Benchmarking could be interesting. For example, if you have lots of small, compressible files and good read locality, read performance could benefit from compression. OTOH, it could function as a building block for 'real compression' - a directory with an inode flag appears as a file, contains a series of small files with numbered names (or ideally without names, write the hash directly); each file is a compressed 4kb block (ordinarily this would not be stored as a tail, but here it is, after compression). This stuff probably gains greatly from a repacker and allocate on flush, and would also be cleaner with v4's plugins. As regards algorithms, e2compr has various - LZO, LZVW, gzip, and a specialised version of bzip2 (definitely not a good idea for tails :)). Also, gzip -8 is not the same as gzip -1. Although there isn't much code likely to be common with e2compr, because it would do different things. > > /Valdis > -- The road to Tycho is paved with good intentions msg04053/pgp0.pgp Description: PGP signature
Re: [reiserfs-list] Tail compression
On Wed, 16 Jan 2002 15:22:45 GMT, toad <[EMAIL PROTECTED]> said: > Hi. Reiserfs packs small files well, and has problems with large tails. > So would it make sense to try to gzip tails before packing? AIX already supports this sort of compression. Interestingly enough, they use LZ compression instead, probably for the following reasons: 1) Consider any patent issues - I think LZW has a problem here. gzip I believe is free, but... 2) Remember that you're only compressing a *tail* - as such, you want something that does a reasonable job for "very short" runs. 'gzip < /dev/null | wc' says 20 characters of overhead - do LZ or other schemes do better? Also, think about the startup CPU cost for each tail on compression/decompression - is gzip optimal or are other things better? Remember - this has different trade-offs than the usual usage of gzip. Usually, you don't bother gzipping unless the file is large, and you don't do it often, so you can afford to be slower to get better compression. For tails, you probably want an algorithm that's 15% faster, even if the result is 15% longer... /Valdis msg04052/pgp0.pgp Description: PGP signature
Re: [reiserfs-list] mount problem
On Wednesday, January 16, 2002 12:36:30 PM +0100 Markus Heller <[EMAIL PROTECTED]> wrote: > hi all, > > but the error as reported is known to you? i mean, the mount command > saying that there is no valid superblock... > > are you sure i didn't do anything wrong? is this a normal error message in > this case? shouldn't the mount command at least say something like ... > "hey, i've found a filesystem, but don't know how to handle it"? Well, the error just means the kernel did not find a filesystem it understood. You've got 3 basic possibilities: 1) reiserfs 3.5 filesystem created by suse 6.3, which is not mountable by current 2.4 or 2.2 kernel patches. 2) reiserfs journaled filesystem that should be mountable, but the kernel didn't have reiserfs compiled in correctly 3) no FS at all. #1 is most likley based on the info so far. You can grab the reiserfs utilities for the 3.5 disk format, and use dumpreiserfs to see if the old filesystem is there. -chris
[reiserfs-list] Tail compression
Hi. Reiserfs packs small files well, and has problems with large tails. So would it make sense to try to gzip tails before packing? I'm going to try to have a go at coding this. -- The road to Tycho is paved with good intentions msg04050/pgp0.pgp Description: PGP signature
Re: [reiserfs-list] Re: Hard disk error. Strange SCSI sense error on HDD. Crash!
On Wednesday, 16. January 2002 16:06, Dieter Nützel wrote: > On Wednesday, 16. January 2002 02:29, pcg( Marc)@goof(A.).(Lehmann )com wrote: > > On Tue, Jan 15, 2002 at 10:24:19PM +0100, Dieter Nützel > > <[EMAIL PROTECTED]> wrote: > > > smartd and smartctl > > > > Do you have a url where one can get these? The homepage only offers the > > very old 2.0beta versions. > > Hello Marc, > > hmm, where did I grep it. --- Sourceforge.net, not sure... > Have to think, again. Ah, found it. http://sourceforge.net/projects/smartsuite/ ftp://ftp.sourceforge.net/pub/sourceforge/smartsuite -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED]
Re: [reiserfs-list] mount problem
Markus Heller wrote: > > hi all, > > but the error as reported is known to you? i mean, the mount command > saying that there is no valid superblock... > Standard message. This is because your backup was created on the old reiserfs that probably doesn't support reiserfs journal. New kernels (like in 7.3) don't know this reiserfs format.. > are you sure i didn't do anything wrong? is this a normal error message in > this case? shouldn't the mount command at least say something like ... > "hey, i've found a filesystem, but don't know how to handle it"? Not sure at 100%: you should also look at the kernel messages after failed mount, but I guess it was something like :'can't find reiserfs filesystem'. If your backup is really important, the only way is to build the old kernel you used before upgrade. I think your backup will be accessible again. Edward. > > Markus > (waiting for the disk to be shipped to me currently) > > On Mon, 14 Jan 2002, Edward Shushkin wrote: > > Chris Mason wrote: > > > On Monday, January 14, 2002 05:29:03 PM +0100 Markus Heller <[EMAIL PROTECTED]> > > > wrote: > > > > i have been running a very old kernel (2.2.something). i saved all my > > > > backup data on a reiser partition, did a backup to suse 7.3 and tried to > > > > remount it, without success. the old suse version was 6.3, however with a > > > > newer 2.2 series kernel. i think it was 2.2.18... > > > SuSE 6.3 shipped with the non-journaled version of reiserfs, which can't be > > > read by current reiserfs versions. I wonder if the journal relocation patch > > > could be used to mount the disk. > > Nope. The relocation patch allows to mount all the file systems that are available > > with non-patched kernel plus non-standard ones. > > Edward. > >
Re: [reiserfs-list] mount problem
hi all, but the error as reported is known to you? i mean, the mount command saying that there is no valid superblock... are you sure i didn't do anything wrong? is this a normal error message in this case? shouldn't the mount command at least say something like ... "hey, i've found a filesystem, but don't know how to handle it"? Markus (waiting for the disk to be shipped to me currently) On Mon, 14 Jan 2002, Edward Shushkin wrote: > Chris Mason wrote: > > On Monday, January 14, 2002 05:29:03 PM +0100 Markus Heller <[EMAIL PROTECTED]> > > wrote: > > > i have been running a very old kernel (2.2.something). i saved all my > > > backup data on a reiser partition, did a backup to suse 7.3 and tried to > > > remount it, without success. the old suse version was 6.3, however with a > > > newer 2.2 series kernel. i think it was 2.2.18... > > SuSE 6.3 shipped with the non-journaled version of reiserfs, which can't be > > read by current reiserfs versions. I wonder if the journal relocation patch > > could be used to mount the disk. > Nope. The relocation patch allows to mount all the file systems that are available > with non-patched kernel plus non-standard ones. > Edward. >
Re: [reiserfs-list] HELP: NFS-related Oops in reiserfs_delete_inode, 2.4.18pre3
Jens Benecke writes: > Hi, > > while deleteing a large directory via NFS today (from Konqueror) I got > this: > Stack trace looks sane up to the last entry: reiserfs_delete_inode+0/152. It's impossible for this function to fail at the first byte of its body. Moreover, destroy_inode() doesn't call reiserfs_delete_inode() at all, but calls kmem_cache_free() in stead. It looks like memory corruption. Either memory is not trustworthy (memtest86 should detect this sooner or later) or some driver accessed a wild pointer within the kernel. > --- > Jan 16 01:45:16 server kernel: Unable to handle kernel NULL pointer dereference at >virtual address 0003 > Jan 16 01:45:16 server kernel: printing eip: > Jan 16 01:45:16 server kernel: c012a162 > Jan 16 01:45:16 server kernel: *pde = > Jan 16 01:45:16 server kernel: Oops: 0002 > Jan 16 01:45:16 server kernel: CPU:0 > Jan 16 01:45:16 server kernel: EIP:0010:[kmem_cache_free+78/148]Not tainted > Jan 16 01:45:16 server kernel: EFLAGS: 00010046 Jan 16 01:45:16 server kernel: eax: >c7914000 ebx: a163 ecx: c1510060 edx: > Jan 16 01:45:16 server kernel: esi: c1406130 edi: 0246 ebp: cc85cf60 esp: >cd443ec4 > Jan 16 01:45:16 server kernel: ds: 0018 es: 0018 ss: 0018 Jan 16 01:45:16 server >kernel: Process nfsd (pid: 31464, stackpage=cd443000) > Jan 16 01:45:16 server kernel: Stack: c1510a00 c01692f0 c0260d40 cc85cf60 c01428f0 >c1406130 c1510a00 c1510a00 > Jan 16 01:45:16 server kernel:c0143c8f c1510a00 c3c899c0 c1510a00 c3c899c0 >c0142398 c1510a00 > Jan 16 01:45:16 server kernel:ccf05a20 c013be96 c3c899c0 c3c899c0 cd3d4404 >c3c899c0 d0d0225f ccf05a20 > Jan 16 01:45:16 server kernel: Call Trace: [reiserfs_delete_inode+0/152] >[destroy_inode+32/40] [iput+399/408] [d_delete+76/108] [vfs_unlink+246/300] > Jan 16 01:45:17 server kernel:[] [] [] >[] [] [] > Jan 16 01:45:17 server kernel:[] [] [] >[kernel_thread+40/56] > Jan 16 01:45:17 server kernel: > Jan 16 01:45:17 server kernel: Code: 89 42 04 89 10 8b 46 10 89 48 04 89 01 8d 46 10 >89 41 04 89 > --- > > The directory contained a couple (3) big files, and about 50 ~3-5MB files. > It was burned to CDR a few minutes before. > > Attached is the ksymoops report. Please check this. This makes me very > uneasy. ALso, I don't understand the symbol warnings (depmod -a doesn't > complain about anything). Ignore them. > > > Thanks! > Nikita.
