linux-kernel - Re: [RFC][PATCH] ChunkFS: fs fission for faster fsck

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]

Date:	Tue, 24 Apr 2007 11:27:25 -0700 (PDT)
From:	David Lang <david.lang@...italinsight.com>
To:	Nikita Danilov <nikita@...sterfs.com>
cc:	Amit Gud <gud@....ksu.edu>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, val_henson@...ux.intel.com,
	riel@...riel.com, zab@...bo.net, arjan@...radead.org,
	suparna@...ibm.com, brandon@...p.org, karunasagark@...il.com,
	gud@....edu
Subject: Re: [RFC][PATCH] ChunkFS: fs fission for faster fsck

On Tue, 24 Apr 2007, Nikita Danilov wrote:

> Amit Gud writes:
>
> Hello,
>
> >
> > This is an initial implementation of ChunkFS technique, briefly discussed
> > at: http://lwn.net/Articles/190222 and
> > http://cis.ksu.edu/~gud/docs/chunkfs-hotdep-val-arjan-gud-zach.pdf
>
> I have a couple of questions about chunkfs repair process.
>
> First, as I understand it, each continuation inode is a sparse file,
> mapping some subset of logical file blocks into block numbers. Then it
> seems, that during "final phase" fsck has to check that these partial
> mappings are consistent, for example, that no two different continuation
> inodes for a given file contain a block number for the same offset. This
> check requires scan of all chunks (rather than of only "active during
> crash"), which seems to return us back to the scalability problem
> chunkfs tries to address.

not quite.

this checking is a O(n^2) or worse problem, and it can eat a lot of memory in 
the process. with chunkfs you divide the problem by a large constant (100 or 
more) for the checks of individual chunks. after those are done then the final 
pass checking the cross-chunk links doesn't have to keep track of everything, it 
only needs to check those links and what they point to

any ability to mark a filesystem as 'clean' and then not have to check it on 
reboot is a bonus on top of this.

David Lang

> Second, it is not clear how, under assumption of bugs in the file system
> code (which paper makes at the very beginning), fsck can limit itself
> only to the chunks that were active at the moment of crash.
>
> [...]
>
> >
> > Best,
> > AG
>
> Nikita.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/