Kernel block cache problems???

Andreas Dilger (adilger@enel.ucalgary.ca)
Tue, 17 Aug 1999 19:50:26 -0600 (MDT)


Hello,
I'm finished most of the implementation of the ext2 online resize (kernel
patch + user-space tools), but I'm consistently having a problem somewhere
in the kernel (2.0.37) that I'm having a problem tracking down.

The kernel performs the requisite action as normal, and the debugging
shows that it is reading the correct data from the disk, and it updates
the superblock and group descriptors in the buffer, but it seemingly
"forgets" these changes to the superblock and GDT within a few seconds
(at least by the time I type "df -k" it is gone.

The reason I think it is a kernel problem of some sort is that for some
small resizes, all I call is ext2_free_blocks(), which does it's job and
all along the code path back from ext2_remount() the data is correct.
After it goes outside the ext2 code, the data is lost. I DO mark the
superblock dirty via:

sb->s_dirt=1; mark_buffer_dirty(sb->u.ext2_sb.s_sbh, 1);

so my understanding is that this would cause any changes made by the kernel
to be written to disk, but in fact old data is being written to disk on top
of data that I had verified was there. I thought that there was a unified
cache between the kernel and user-space, is this not the case? If not, where
is the other copy of the superblock and GDT block so I can update it as well?

Cheers, Andreas
--- output from syslog with debug, check=strict and ext2-online patch ---
### Start with 10MB filesystem ###
Aug 16 23:33:06 webber kernel: [EXT II FS 0.5b, 95/08/09, bs=1024, bc=10240,
gc=2, bpg=8192, ipg=512, mo=000b]
Aug 16 23:33:06 webber kernel: group 0: stored = 8111, counted = 8111
Aug 16 23:33:06 webber kernel: group 1: stored = 1979, counted = 1979
Aug 16 23:33:06 webber kernel: ext2_count_free_blocks: stored = 10090,
### Try to resize the filesystem to 12MB (12288 blocks) ###
Aug 16 23:33:23 webber kernel: EXT2-fs: parse_options: resize=12288
Aug 16 23:33:23 webber kernel: EXT2-fs: ext2_resize_fs: from 10240 to 12288
blocks
Aug 16 23:33:23 webber kernel: EXT2-fs: ext2_read_descriptors: o_groups_count=2,
groups_count=2, blocks_count=12288
Aug 16 23:33:23 webber kernel: EXT2-fs: ext2_read_descriptors: db_orig=1,
db_start=1, db_count=1
### Freeing 2048 blocks in group 1, so far so good, we have 12288 blocks ###
Aug 16 23:33:23 webber kernel: EXT2-fs: ext2_resize_fs: added 2048 new blocks
to 10240 current blocks
Aug 16 23:33:23 webber kernel: [EXT II FS 0.5b, 95/08/09, bs=1024, bc=12288,
gc=2, bpg=8192, ipg=512, mo=000b]
### At ext2_setup_super() at the end of ext2_remount() shows all is well ###
### in the GDT and superblock, as well as the group 1 block bitmap ###
Aug 16 23:33:23 webber kernel: group 0: stored = 8111, counted = 8111
Aug 16 23:33:23 webber kernel: group 1: stored = 4027, counted = 4027
Aug 16 23:33:23 webber kernel: ext2_count_free_blocks: stored = 12138,
computed gdt = 12138, bitmap = 12138
### At this point, my code is finished, and ext2_remount() returns, but ###
### seconds later, when I do "df -k" on the FS, the output from ###
### ext2_count_free_blocks() is the old data in the GDT and superblock, ###
### even on disk (not the block bitmap, however)!!! What is wrong???? ###
Aug 16 23:33:30 webber kernel: group 0: stored = 8111, counted = 8111
Aug 16 23:33:30 webber kernel: group 1: stored = 1979, counted = 4027
Aug 16 23:33:30 webber kernel: ext2_count_free_blocks: stored = 10090,
computed gdt = 10090, bitmap = 12138
--- end of syslog output ---

-- 
Andreas Dilger  University of Calgary \ "If a man ate a pound of pasta and
                Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \  cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/      hungry?" -- Dogbert

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/