linux-kernel - Re: Tux3 Report: Initial fsck has landed

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: <alpine.DEB.2.02.1301272158450.13067@nftneq.ynat.uz>
Date:	Sun, 27 Jan 2013 22:02:42 -0800 (PST)
From:	David Lang <david@...g.hm>
To:	Daniel Phillips <daniel.raymond.phillips@...il.com>
cc:	linux-kernel@...r.kernel.org, tux3@...3.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: Tux3 Report: Initial fsck has landed

On Sun, 27 Jan 2013, Daniel Phillips wrote:

> Compared to Ext2/3/4, Tux3 has a big disadvantage in terms of fsck: it does
> not confine inode table blocks to fixed regions of the volume. Tux3 may store
> any metadata block anywhere, and tends to stir things around to new locations
> during normal operation. To overcome this disadvantage, we have the concept of
> uptags:
>
>    http://phunq.net/pipermail/tux3/2013-January/001973.html
>    "What are uptags?"
>
> With uptags we should be able to fall back to a full scan of a damaged volume
> and get a pretty good idea of which blocks are actually lost metadata blocks,
> and to which filesystem objects they might belong.

The thing that jumps out at me with this is the question of how you will avoid 
the 'filesystem image in a file' disaster that reiserfs had (where it's fsck 
could mix up metadata chunks from the main filesystem with metadata chunks from 
any filesystem images that it happened to stumble across when scanning the disk)

many people with dd if=/dev/sda2 of=filesystem.image, and if you are doing 
virtualization, you may be running out of one of these filesystem images. With 
virtualization, it's very likely that you will have many copies of a single 
image that are all identical.

have you thought of how to deal with this problem?

David Lang
--
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/