Util-Linux package development
 help / color / mirror / Atom feed
From: Stanislav Brabec <sbrabec@suse.cz>
To: "Theodore Ts'o" <tytso@mit.edu>, Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH] fsck: implement fsck -r {fd}
Date: Tue, 28 Apr 2015 17:56:08 +0200	[thread overview]
Message-ID: <553FAD98.5070202@suse.cz> (raw)
In-Reply-To: <20150428141558.GA2569@thunk.org>

Theodore Ts'o wrote:

> We're not parsing the output; it's something that we look at in the
> log files manually (i.e., by humans when trying to debug a problem.)

SUSE boot scripts parse this output (well, it uses just a part of the 
information) to synchronize fsck and quota activation. Passing an opened 
file descriptor is a good solution for these purposes.

This needs just the one-line statistics generated by fsck, underlying FS 
specific statistics are not needed.

> The bigger deal for us not just mixing the stats and the rest of the
> fsck output, but if you have dozen(s) of disks after a power failure,
> and you're running without a journal, multiple drives will have
> inconsistencies that need fixing, and so we divert the output for each
> fsck process to a separate log file for each fsck process / file
> system.

My patch just allows separating of the progress and statistics, but not 
splitting it per volume. (If you want human readable output, please see 
my reply to this note. (e. g. use -r -3).

Splitting per volumen is another issue, and use of -C {fd} is 
insufficient for it. But -r {fd} is probably sufficient for all use 
cases of the one-line-per-volume summary statistics.

fsck can now use only a subset of e2fsck features.

> The changes to separate out the fsck output into separate files is a
> change which I don't think ever made it upstream.  IIRC, we submitted
> the patches upstream, there were some objections, and I never had time
> to get back to trying to make something that would work for us and
> acceptable upstream; my bad.  If you want I can try to dig it up and
> try resubmitting it.

The format of the machine parseable output of -C {fd} allows to separate 
progress for particular discs, but yes, if you want them separated and 
human readable, it is a bad approach to do it that way.

I can imagine better configurability of fsck, and maybe seamless 
integration with udev/systemd. But I have no idea what is the best way.

Keeping a possibility to send progress to an opened FD is required by 
GUI frontends, so it needs to be kept.

  I suspect the right answer is to
> get something like this into fsck, but the problem is where to put the
> formatting information, since fsck doesn't a configuration file ala
> /etc/e2fsck.conf, where something like this can be dropped:

Configuration file could be a solution. SUSE could easily live even 
without it, so I cannot give an advice how to do it best.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@suse.cz
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76

  reply	other threads:[~2015-04-28 15:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27 15:20 [PATCH] fsck: implement fsck -r {fd} Stanislav Brabec
2015-04-28 11:52 ` Karel Zak
2015-04-28 14:15   ` Theodore Ts'o
2015-04-28 15:56     ` Stanislav Brabec [this message]
2015-04-28 17:13       ` Theodore Ts'o
2015-04-28 18:30         ` Stanislav Brabec
2015-04-28 15:28   ` Stanislav Brabec

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=553FAD98.5070202@suse.cz \
    --to=sbrabec@suse.cz \
    --cc=kzak@redhat.com \
    --cc=tytso@mit.edu \
    --cc=util-linux@vger.kernel.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