linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: Andreas Dilger <adilger@dilger.ca>
Cc: Nebojsa Trpkovic <trx.lists@gmail.com>, linux-ext4@vger.kernel.org
Subject: Re: lifetime_write_kbytes isn't preserved during unclean shutdown
Date: Wed, 30 Jun 2010 09:31:08 -0400	[thread overview]
Message-ID: <20100630133108.GD1333@thunk.org> (raw)
In-Reply-To: <519E1F03-CD95-41F4-B2EE-93983A4CC08A@dilger.ca>

On Tue, Jun 29, 2010 at 11:46:57PM -0600, Andreas Dilger wrote:
> On 2010-06-28, at 13:57, tytso@mit.edu wrote:
> > On Sun, Jun 27, 2010 at 06:56:07PM +0200, Nebojsa Trpkovic wrote:
> >> I've noticed that lifetime_write_kbytes isn't preserved during unclean
> >> shutdown.
> > 
> > Yes, right now we are only updating the superblock's lifetime write
> > kbytes at unmount time.  It should be possible to do a better job; but
> > I don't want to increase writes to the disk just to keep the
> > s_lifetime value up-to-date.  So what we should probably do is update
> > it when we are going to be updating the superblock anyway (i.e., when
> > we update the orphaned inode linked list)
> 
> Could we also update the superblock blocks/inodes free counters at
> that time as well?

Remind me again why you wanted it.  You had some use case where you
wanted to be able to read the file system's block device directly and
have vaguely correct free inode/block numbers in the superblock?

> I don't think that is the right thing to do, unless the filesystem
> is still active for other reasons.  We don't necessarily want to
> spin up the disks every hour if the filesystem is inactive, I'd
> rather write out the superblock for an existing transaction while it
> is still active than generate a new transaction for no particular
> reason.
> 
> One way to do this would be to have a JBD transaction pre-commit
> callback, and if the superblock has not been written in N seconds
> then it can be added as part of that transaction (if it will fit).
> If it is already in the transaction it can be updated via the
> existing bh callbacks that OCFS2 is using.

That seems reasonable way of doing things.  I think N seconds should
be in the region of every 5-60 minutes, though.  And yes, absolutely
we wouldn't want to spin up the disk if there was no other activity.

   	    	    	    	- Ted

  reply	other threads:[~2010-06-30 13:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-27 16:56 lifetime_write_kbytes isn't preserved during unclean shutdown Nebojsa Trpkovic
2010-06-28 19:57 ` tytso
2010-06-30  5:46   ` Andreas Dilger
2010-06-30 13:31     ` tytso [this message]
2010-06-30 21:54       ` Andreas Dilger

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=20100630133108.GD1333@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=trx.lists@gmail.com \
    /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).