All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mingming Cao <cmm@us.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: Peter Staubach <staubach@redhat.com>,
	Eric Sandeen <sandeen@redhat.com>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: delayed allocation i_blocks fix for stat(2)
Date: Tue, 08 Jul 2008 15:55:19 -0700	[thread overview]
Message-ID: <1215557719.6820.14.camel@mingming-laptop> (raw)
In-Reply-To: <20080708200235.GC22477@atrey.karlin.mff.cuni.cz>


在 2008-07-08二的 22:02 +0200,Jan Kara写道:
> > Eric Sandeen wrote:
> > >Mingming Cao wrote:
> > >  
> > >>ext4: delayed allocation i_blocks fix for stat(2)
> > >>
> > >>From: Mingming Cao <cmm@us.ibm.com>
> > >>
> > >>Right now i_blocks is not getting updated until the disks are actually
> > >>allocaed on disk.  This means with delayed allocation, right after files
> > >>are copied, "ls -sF" shoes the file as taking 0 blocks on disk.  "du"
> > >>also shows the files taking zero space, which is highly confusing to the 
> > >>user.
> > >>
> > >>Since current delayed allocation already keep track of per-inode total 
> > >>number
> > >>of blocks that are subject to delayed allocation, this patch fix this by 
> > >>using
> > >>that to adjust the value returned by stat(2). When real block allocation
> > >>is done, the i_blocks will get updated. Since the reserved blocks for 
> > >>delayed
> > >>allocation will be decreased, this will be keep value returned by stat(2)
> > >>consistent.
> > >>
> > >>Signed-off-by: Mingming Cao <cmm@us.ibm.com>
> > >>    
> > >
> > >Thanks Mingming, looks like just the right approach.
> > >
> > >Something about the spinlock for every stat seems heavy-handed to me but
> > >I'll have to give that more thought.  :)
> > >
> > >  
> > 
> > Since i_reserved_blocks is an unsigned long, it should be possible
> > to atomically fetch it on all of the supported architectures,
> > without the use of the spinlock.  It seems to me that this spinlock
> > is not required here.
>   Well, it's certainly not nice to rely on this. The clean solution
> would be to convert i_reserved_blocks to atomic_t or atomic64_t on archs
> that have it...
> 

I was thinking about the same thing when this lock was initially
introduced ... but this lock is protecting three counters, and these
counters are updated/reset in a couple of places, and being used to
calcuate how much per-fs free blocks counter need to be accounted.  It's
doable, just need a careful look if we make them all atomic.

Mingming


> 								Honza

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2008-07-08 22:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-07 23:36 [PATCH] ext4: delayed allocation i_blocks fix for stat(2) Mingming Cao
2008-07-07 23:47 ` Theodore Tso
2008-07-08  1:11 ` Eric Sandeen
2008-07-08 12:15   ` Peter Staubach
2008-07-08 20:02     ` Jan Kara
2008-07-08 22:55       ` Mingming Cao [this message]

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=1215557719.6820.14.camel@mingming-laptop \
    --to=cmm@us.ibm.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=staubach@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.