lkml.org 
[lkml]   [2013]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2013-01-28 08:01    [W:0.061 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site