2009/12/16 Evgeniy Polyakov <[email protected]>:
> Hi Alexander.
>
> Sorry for late response.
>
> On Sat, Dec 12, 2009 at 02:46:52AM +0300, Alexander Beregalov
> ([email protected]) wrote:
>> The kernel is 2.6.32-05775-gaad3bf0-dirty now.
>> This is my fix to avoid bdi_sync_writeback().
>
> This will not work, since sync_filesystem() will not actually sync any
> inodes because there is no bdi - it will just return. And prior syncing
> is required to flush all pending inodes to the state when they can be
> dropped by kill_anon_super(), otherwise it will spawn warnings about
> inodes being used.
Then can you provide the right fix?
It seems to me that this "fix" might(does?) produce the problem.
>
>> diff --git a/drivers/staging/pohmelfs/inode.c
>> b/drivers/staging/pohmelfs/inode.c
>> index f69b778..3e5826f 100644
>> --- a/drivers/staging/pohmelfs/inode.c
>> +++ b/drivers/staging/pohmelfs/inode.c
>> @@ -1941,7 +1941,7 @@ static int pohmelfs_get_sb(struct
>> file_system_type *fs_type,
>> */
>> static void pohmelfs_kill_super(struct super_block *sb)
>> {
>> - sync_inodes_sb(sb);
>> + sync_filesystem(sb);
>> kill_anon_super(sb);
>> }
>>
>> The problem is somewhere in sync/cache code.
>>
>> tar jxf linux.tar.bz2
>> make defconfig
> ...
>> Client's dmesg is too noisy to find something useful.
>
> As of problem you caught, I believe only client log will be able to show
> the light on this, since it writes basically everything system did with
> inodes. I would ask you to squeeze test case as much as possible to find
> out the problem, since having kernel untar being logged likely will not
> help us much.
>
> Thanks a lot!
>
> --
> Evgeniy Polyakov
>
_______________________________________________
Pohmelfs mailing list
[email protected]
http://www.ioremap.net/cgi-bin/mailman/listinfo/pohmelfs
