Re: [reiserfs-list] 'let the hdd remap the bad blocks'
Hans Reiser [EMAIL PROTECTED] writes: Just taking a guess, many hard drives have difficult and time-consuming procedures that they can go through to read a troublesome block. These can take 20-30 seconds. Probably if they have to go through these procedures, once they finally succeed the smart vendors remap the block. They should try to rewrite and write verify the block before remapping it, as there is only a finite amount of spares. For SCSI drives, there's also Jörg Schilling's sformat tool that can do the badblocks stuff directly in the drive rather than through all the kernel buffers, and can also refresh or reassign bad blocks. -- Matthias Andree
Re: [reiserfs-list] 'let the hdd remap the bad blocks'
Matthias Andree wrote: Hans Reiser [EMAIL PROTECTED] writes: Just taking a guess, many hard drives have difficult and time-consuming procedures that they can go through to read a troublesome block. These can take 20-30 seconds. Probably if they have to go through these procedures, once they finally succeed the smart vendors remap the block. They should try to rewrite and write verify the block before remapping it, as there is only a finite amount of spares. For SCSI drives, there's also Jörg Schilling's sformat tool that can do the badblocks stuff directly in the drive rather than through all the kernel buffers, and can also refresh or reassign bad blocks. Vitaly, take a look at that. Part of a good user interface is letting users know what tools are available. Remember, most users will encounter a failing drive and/or fsck on a journaling fs as a rare and stressful event in their lives, so it is good to educate them with URLs and other references at the time they run fsck.
Re: [reiserfs-list] 'let the hdd remap the bad blocks'
On Tue, 20 Aug 2002, Hans Reiser wrote: Vitaly, take a look at that. Part of a good user interface is letting users know what tools are available. Remember, most users will encounter a failing drive and/or fsck on a journaling fs as a rare and stressful event in their lives, so it is good to educate them with URLs and other references at the time they run fsck. A propos URL, here we go: ftp://ftp.fokus.gmd.de/pub/unix/sformat/ -- Matthias Andree
[reiserfs-list] quota support ?
Hi, All ! Who know, will quota support and fs at all be working, if my kernel is 2.4.19 version, and make the patches for quota support from reiserfs site ? The problem is that reiser's patches are for 2.4.19-pre3, not clean 2.4.19. --- Serge Kolodeznyh Paradigma AG Network /system administrator SVK42-RIPN / SVK33-RIPE
Re: [reiserfs-list] quota support ?
Hello! On Tue, Aug 20, 2002 at 05:12:09PM +0400, Serge Kolodeznyh wrote: Who know, will quota support and fs at all be working, if my kernel is 2.4.19 version, and make the patches for quota support from reiserfs site ? The problem is that reiser's patches are for 2.4.19-pre3, not clean 2.4.19. This is not a problem. Everything should work fine if applies correctly. Bye, Oleg
Re: [reiserfs-list] quota support ?
Last patch doesn't apllied :-(
[root@helios linux-2.4.19]# gzip -cd kinoded-8-2.4.19-pre3.diff.gz |
patch -p1
patching file fs/inode.c
Hunk #4 FAILED at 698.
Hunk #5 succeeded at 1119 (offset -1 lines).
Hunk #7 succeeded at 1278 (offset -1 lines).
1 out of 7 hunks FAILED -- saving rejects to file fs/inode.c.rej
inode.c.rej:
***
*** 697,731
spin_unlock(inode_lock);
dispose_list(freeable);
/*
- * If we didn't freed enough clean inodes schedule
- * a sync of the dirty inodes, we cannot do it
- * from here or we're either synchronously dogslow
- * or we deadlock with oom.
*/
if (goal)
- schedule_task(unused_inodes_flush_task);
}
int shrink_icache_memory(int priority, int gfp_mask)
{
int count = 0;
-
- /*
- * Nasty deadlock avoidance..
- *
- * We may hold various FS locks, and we don't
- * want to recurse into the FS that called us
- * in clear_inode() and friends..
- */
- if (!(gfp_mask __GFP_FS))
- return 0;
-
count = inodes_stat.nr_unused / priority;
-
prune_icache(count);
- kmem_cache_shrink(inode_cachep);
return 0;
}
--- 698,729
spin_unlock(inode_lock);
dispose_list(freeable);
+ kmem_cache_shrink(inode_cachep);
/*
+ * If we didn't freed enough clean inodes
+ * start a sync now
*/
if (goal)
+ try_to_sync_unused_inodes();
+ }
+
+ void prune_icache(int goal) {
+ if (!atomic_read(kinoded_goal)) {
+ atomic_set(kinoded_goal, goal) ;
+ wake_up_interruptible(kinoded_wait);
+ }
+ /* otherwise, kinoded has already been woken up, move on
+ ** to other caches that might be shrinkable instead of spending time
+ ** waiting for kinoded to make progress
+ */
}
int shrink_icache_memory(int priority, int gfp_mask)
{
int count = 0;
count = inodes_stat.nr_unused / priority;
prune_icache(count);
return 0;
}
---
Serge Kolodeznyh
Paradigma AG
Network /system administrator
SVK42-RIPN / SVK33-RIPE
- Original Message -
From: Oleg Drokin [EMAIL PROTECTED]
To: Serge Kolodeznyh [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, August 20, 2002 5:15 PM
Subject: Re: [reiserfs-list] quota support ?
Hello!
On Tue, Aug 20, 2002 at 05:12:09PM +0400, Serge Kolodeznyh wrote:
Who know, will quota support and fs at all be working, if my kernel is
2.4.19 version, and make the patches for quota support from reiserfs
site ?
The problem is that reiser's patches are for 2.4.19-pre3, not clean
2.4.19.
This is not a problem. Everything should work fine if applies correctly.
Bye,
Oleg
Re: [reiserfs-list] quota support ?
On Tue, 2002-08-20 at 10:24, Serge Kolodeznyh wrote: Last patch doesn't apllied :-( [root@helios linux-2.4.19]# gzip -cd kinoded-8-2.4.19-pre3.diff.gz | patch -p1 patching file fs/inode.c Hunk #4 FAILED at 698. Hunk #5 succeeded at 1119 (offset -1 lines). Hunk #7 succeeded at 1278 (offset -1 lines). 1 out of 7 hunks FAILED -- saving rejects to file fs/inode.c.rej I'll release an updated set of patches later this week. -chris
[reiserfs-list] Corruptions on every filesystem with 02-reiserfs_file_write.diff.gz
When applying the second of the patches available under reiserfs-for-2.4/2.4.19.pending/testing I get corruptions on any write comitted to ANY filesystem, including ram. I cannot give more specifics than adding that patch, doing a simple test like creating a tar.bz2 out of a folder on my HD (be it SCSI or IDE), produces a corrupt archive; i.e. testing it with 'bzip2 -t' gives a CRC error on the archive. The oddest part is that it does not only affect to reiserfs partitions, but to any file created on ext2, xfs or even ramfs (/dev/shm) partitions. This behaviour was the same with either 2.4.19-pre5-aa1 (aka 2.4.19-aa), 2.4.19 barebone, 2.4.20-pre2, 2.4.20-pre-ac2 ac3 and ac4. In each of them I had applied the corresponding patches of the main 2.4.19.pending dir which had not been previously merged on the kernel. I tried different things to avoid those corruptions I was suddenly getting until I began removing the patches I had applied to all my testing kernels, and the culprit was 02-reiserfs_file_write.diff.gz The first one gave no problems, although to be on the safe side, I have removed it too. I attach some relevant information about my system. Let me reinforce the fact that without that I have no problems at all, and reiserfs is working better than ever :) Linux version 2.4.20-p2ac4-rmap14a (root@) (gcc version 3.2) BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0ffec000 (usable) BIOS-e820: 0ffec000 - 0ffef000 (ACPI data) BIOS-e820: 0ffef000 - 0000 (reserved) BIOS-e820: 0000 - 1000 (ACPI NVS) BIOS-e820: - 0001 (reserved) 255MB LOWMEM available. On node 0 totalpages: 65516 zone(0): 4096 pages. zone(1): 61420 pages. zone(2): 0 pages. Kernel command line: root=/dev/sda2 video=matrox:mem:32,xres:1280,yres:960,left:264,right:24,hslen:160,upper:47,lower:1,vslen:3,pixclock:6024,sync:0x03,depth:32,pan,panicblink=2,devfs=mount Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC! Initializing CPU#0 Detected 1544.517 MHz processor. Console: colour dummy device 80x25 Calibrating delay loop... 3080.19 BogoMIPS Memory: 254120k/262064k available (1379k kernel code, 5512k reserved, 438k data, 108k init, 0k highmem) Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode cache hash table entries: 16384 (order: 5, 131072 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) ramfs: mounted with options: defaults ramfs: max_pages=32020 max_file_pages=0 max_inodes=0 max_dentries=32020 Buffer cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) CPU: Before vendor init, caps: 0383fbff c1c3fbff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0383fbff c1c3fbff Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff c1c3fbff CPU: Common caps: 0383fbff c1c3fbff CPU: AMD Athlon(TM) XP 1800+ stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: Using local APIC timer interrupts. calibrating APIC timer ... . CPU clock speed is 1544.6280 MHz. . host bus clock speed is 268.6308 MHz. cpu: 0, clocks: 2686308, slice: 1343154 CPU0T0:2686304,T1:1343136,D:14,S:1343154,C:2686308 mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1 PCI: Probing PCI hardware Disabling VIA memory write queue (PCI ID 0305, rev 03): [55] 89 1f - 09 Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 Applying VIA southbridge workaround. PCI: Disabling Via external APIC routing PnPBIOS: Found PnP BIOS installation structure at 0xc00fc4f0 PnPBIOS: PnP BIOS version 1.0, entry 0xf:0xc520, dseg 0xf PnPBIOS: 15 nodes reported by PnP BIOS; 15 recorded by driver PnPBIOS: PNP0c02: ioport range 0xe400-0xe47f has been reserved PnPBIOS: PNP0c02: ioport range 0xe800-0xe83f could not be reserved Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd devfs: v1.12a (20020514) Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x0 ACPI: Core Subsystem version [20011018] ACPI: Subsystem enabled ACPI: System firmware supports S0 S1 S4 S5 Processor[0]: C0 C1 C2, 8 throttling
Re: [reiserfs-list] Corruption: --fix-fixable results in all nlinkvalues = 0
On Mon, 2002-08-19 at 06:20, Oleg Drokin wrote: Hello! On Mon, Aug 19, 2002 at 02:07:26PM +0400, Hans Reiser wrote: He suggests that user should specify list of bad blocks each time user runs reiserfsck. This sounds reasonable. You can probably even have a default location Not for me. to check for the list somewhere in /etc if you want. Remind the user File can get corrupted too. You'd have to include some kind of checksum of the bad blocks lists to make sure it was valid, regardless of where you stored it. The problem is that if you store it in the tree somehow, you've got a chicken and egg problem that you can't read the list until the tree is good and you can read the tree without knowing which blocks are bad. It needs to be stored outside the btree, in its own data structure. This could be a file on a different filesystem, or on a floppy, or in something special you put into the FS. -chris
Re: [reiserfs-list] big reiserfs regression in 2.4.20-pre2
Is regression going away if you pass this mount option to reiserfs: -o alloc=preallocmin=4:preallocsize=9 Yes. Great, I just found that we forgot to enable preallocation with new block allocator by default. This is easily fixable of course. Is that in the 2.5.patch: http://marc.theaimsgroup.com/?l=linux-kernelm=102984193227185w=2 Or will it be different for 2.4? -- Randy Hron http://home.earthlink.net/~rwhron/kernel/bigbox.html
Re: [reiserfs-list] big reiserfs regression in 2.4.20-pre2
Hello! On Tue, Aug 20, 2002 at 11:26:32PM -0400, [EMAIL PROTECTED] wrote: Great, I just found that we forgot to enable preallocation with new block allocator by default. This is easily fixable of course. Is that in the 2.5.patch: http://marc.theaimsgroup.com/?l=linux-kernelm=102984193227185w=2 Yes, I included it into 2.5 patch, since I see no reason to supply buggy patch and then several bugfixes. Bye, Oleg
Re: [reiserfs-list] Corruption: --fix-fixable results in all nlink values = 0
Hello! On Tue, Aug 20, 2002 at 04:24:13PM -0400, Chris Mason wrote: make sure it was valid, regardless of where you stored it. The problem is that if you store it in the tree somehow, you've got a chicken and egg problem that you can't read the list until the tree is good and you can read the tree without knowing which blocks are bad. With carefully choosen key, it will be in fixed tree position. But well, if Hans decided it should not be stored in a tree - so be it. Bye, Oleg
Re: [reiserfs-list] Corruptions on every filesystem with 02-reiserfs_file_write.diff.gz
Hello! On Tue, Aug 20, 2002 at 05:17:01PM +0200, Javier Marcet wrote: When applying the second of the patches available under reiserfs-for-2.4/2.4.19.pending/testing I get corruptions on any write comitted to ANY filesystem, including ram. This is very strange, I cannot reproduce anything even remotely similar to this. The only difference I see now is that I compile with gcc 2.95.3 I cannot give more specifics than adding that patch, doing a simple test like creating a tar.bz2 out of a folder on my HD (be it SCSI or IDE), produces a corrupt archive; i.e. testing it with 'bzip2 -t' gives a CRC error on the archive. Just tried copying several kernel trees, archiving kernel trees and stuff and have not seen any corruption. This behaviour was the same with either 2.4.19-pre5-aa1 (aka 2.4.19-aa), 2.4.19 barebone, 2.4.20-pre2, 2.4.20-pre-ac2 ac3 and ac4. In each of them I had applied the corresponding patches of the main 2.4.19.pending dir which had not been previously merged on the kernel. You said XFS, does that mean you had XFS patched in too in all cases? Let me reinforce the fact that without that I have no problems at all, and reiserfs is working better than ever :) We do not create patches to corrupt user's data, we try to enhance what we have now, instead. BTW, have anyone else tried these (or other slightly different patches I uploaded yesterday) patches and observed any data corruptions? Thank you for feedback. Bye, Oleg
