linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viacheslav Dubeyko <slava@dubeyko.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>,
	lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	Vyacheslav.Dubeyko@wdc.com
Subject: Re: [LSF/MM TOPIC] online filesystem repair
Date: Sun, 15 Jan 2017 16:01:30 -0800	[thread overview]
Message-ID: <1484524890.27533.16.camel@dubeyko.com> (raw)
In-Reply-To: <20170114075452.GJ14033@birch.djwong.org>

On Fri, 2017-01-13 at 23:54 -0800, Darrick J. Wong wrote:
> Hi,
> 
> I've been working on implementing online metadata scrubbing and
> repair
> in XFS.  Most of the code is self contained inside XFS, but there's a
> small amount of interaction with the VFS freezer code that has to
> happen
> in order to shut down the filesystem to rebuild the extent backref
> records.  It might be interesting to discuss the (fairly slight)
> requirements upon the VFS to support repairs, and/or have a BoF to
> discuss how to build an online checker if any of the other
> filesystems
> are interested in this.
> 

How do you imagine a generic way to support repairs for different file
systems? From one point of view, to have generic way of the online file
system repairing could be the really great subsystem. But, from another
point of view, every file system has own architecture, own set of
metadata and own way to do fsck check/recovering. As far as I can
judge, there are significant amount of research efforts in this
direction (Recon [1], [2], for example). But we still haven't any real
general online file system repair subsystem in the Linux kernel. Do you
have some new insight? What's difference of your vision? If we have
online file system repair subsystem then how file system driver will
need to interact with the goal to make internal repairing?

Thanks,
Vyacheslav Dubeyko.

[1] http://www.eecg.toronto.edu/~ashvin/publications/recon-fs-consistency-runtime.pdf
[2] https://www.researchgate.net/publication/269300836_Managing_the_file_system_from_the_kernel


  reply	other threads:[~2017-01-16  0:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-14  7:54 [LSF/MM TOPIC] online filesystem repair Darrick J. Wong
2017-01-16  0:01 ` Viacheslav Dubeyko [this message]
2017-01-17  6:24   ` Darrick J. Wong
2017-01-17 20:45     ` Andreas Dilger
2017-01-18  0:37     ` Slava Dubeyko
2017-01-25  8:41       ` Darrick J. Wong
2017-01-27 22:06         ` Slava Dubeyko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1484524890.27533.16.camel@dubeyko.com \
    --to=slava@dubeyko.com \
    --cc=Vyacheslav.Dubeyko@wdc.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).