linux-ext4 - Re: Mentor for a GSoC application wanted (Online ext2/3 filesystem checker)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ej9085dq.fsf@basil.nowhere.org>
Date:	Mon, 21 Apr 2008 01:37:37 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Theodore Tso <tytso@....edu>
Cc:	Alexey Zaytsev <alexey.zaytsev@...il.com>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Rik van Riel <riel@...riel.com>
Subject: Re: Mentor for a GSoC application wanted (Online ext2/3 filesystem checker)

Theodore Tso <tytso@....edu> writes:
>
> If you are going to store all of the cached objects then you will need
> to effectively store *all* of the filesystem metatdata in memory at
> the same time. 

Are you sure about all data? I think he would just need some lookup table from 
metadata block numbers to inode numbers and then when a hit occurs on a block
in  the table somehow invalidate all data related to that inode
and restart that part. And the same thing for bitmap blocks. That lookup
table should be much smaller than the full metadata.

Anyways my favourite fsck wish list feature would be a way to record the 
changes a read-only fsck would want to do and then some quick way
to apply them to a writable version of the file system without 
doing a full rescan. Then you could regularly do a background check
and if it finds something wrong just remount and apply the changes
quickly.

Or perhaps just tell the kernel which objects is suspicious and
should be EIOed.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html