i am reading the scheme by which journal works.
i came to know that after every transaction writen to the log file a 512 byte
sector is writen back to the disk. this is treated as a commit block, and there
is some sequence number in there that matches with all the previous transaction
has bee
Andrew Morton wrote:
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
Here is my first cut at adding writepages() support for
ext3 writeback mode.
Looks sane from a brief scan.
Well, not really..
mpage_writepages() could end up calling ext3_writeback_writepage()
in "confused" case thro ..
*ret
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> Here is my first cut at adding writepages() support for
> ext3 writeback mode.
Looks sane from a brief scan.
> I have not done any performance analysis on the patch,
Please do ;)
> +static int ext3_writepages_get_block(struct inode *inode, se
Hi,
Here is my first cut at adding writepages() support for
ext3 writeback mode.
I have not done any performance analysis on the patch,
so try it at your own risk.
Please let me know, if I am completely off or its a
stupid idea.
Thanks,
Badari
--- linux-2.6.10.org/fs/ext3/inode.c2004-12-
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> I need to teach writepages() to nothing in case of no dirty pages.
> Is there a easy way like checking a count somewhere than doing all the
> stuff mpage_writepages() is doing to figure this out
if (!mapping_tagged(mapping, PAGECACHE_TAG_DIR
I went back and looked more closely and see that you did more than add a
->writepages method. You replaced the ->prepare_write with one that
doesn't involve the buffer cache, right? And from your answer to Badari's
question about that, I believe you said this is not an integral part of
having
On Thu, 2005-02-10 at 15:12, Stephen C. Tweedie wrote:
> Hi,
>
> On Thu, 2005-02-10 at 20:21, Andrew Morton wrote:
>
> > > But I still don't understand why this can't happen
> > > thro original code ..
>
> > > what am i missing ?
> >
> > presumably there are never any dirty pages or inodes wh
Hi,
On Thu, 2005-02-10 at 20:21, Andrew Morton wrote:
> > But I still don't understand why this can't happen
> > thro original code ..
> > what am i missing ?
>
> presumably there are never any dirty pages or inodes when we run
> journal_destroy().
I assume so, yes. If there is no a_ops->wr
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> When the lockfs patches went in an important bit got lost, the call in
> generic_file_write to put newly incoming writers to sleep when a
> filesystem is frozen. Nathan added back the call in the now separate
> XFS write patch, and the patch for the
On Thu, Feb 10, 2005 at 12:30:23PM -0800, Bryan Henderson wrote:
> >Its possible that by doing larger
> >IOs we save CPU and use that CPU to push more data ?
>
> This is absolutely right; my mistake -- the relevant number is CPU seconds
> per megabyte moved, not CPU seconds per elapsed second.
>
>Its possible that by doing larger
>IOs we save CPU and use that CPU to push more data ?
This is absolutely right; my mistake -- the relevant number is CPU seconds
per megabyte moved, not CPU seconds per elapsed second.
But I don't think we're close enough to 100% CPU utilization that this
expla
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> But I still don't understand why this can't happen
> thro original code ..
>
> journal_destory()
> iput(journal inode)
> do_writepages()
> generic_writepages()
>
On Thu, Feb 10, 2005 at 09:39:05AM -0800, Badari Pulavarty wrote:
> On Wed, 2005-02-09 at 08:37, Stephen C. Tweedie wrote:
> > Hi,
> >
> > On Wed, 2005-02-09 at 16:18, Badari Pulavarty wrote:
> >
> > > I am trying to understand journaling code in ext3.
> > > Can some one enlighten me, why we nee
Okay, I figured out why I am getting OOPS from mod_timer.
Its because journal_destory() stopped the kjournald()
which deleted the transaction timer. journal_start()
is adding the timer back again - since its deleted,
I get OOPs.
But I still don't understand why this can't happen
thro original code
On Thu, Feb 10, 2005 at 09:51:42AM -0800, Bryan Henderson wrote:
> >I am inferring this using iostat which shows that average device
> >utilization fluctuates between 83 and 99 percent and the average
> >request size is around 650 sectors (going to the device) without
> >writepages.
> >
> >With wr
to den 10.02.2005 Klokka 12:01 (-0700) skreiv Andreas Dilger:
> This will OOPS if fstype is bad, since you unconditionally put_filesystem()
> on a possible PTR_ERR() type. You need an extra
>
> if (!IS_ERR(type))
> put_filesystem(type);
>
Agreed. That was not a final patch,
On Feb 10, 2005 13:41 -0500, Trond Myklebust wrote:
> +struct vfsmount *
> +do_kern_mount(const char *fstype, int flags, const char *name, void *data)
> +{
> + struct file_system_type *type = get_fs_type(fstype);
> + struct vfsmount *mnt = vfs_kern_mount(type, flags, name, data);
> + p
Hi,
I'm working on straightening out a problem we have with NFSv4 in the
case where the server exports a tree of filesystems (as we also do in
NFSv2/v3 with the "nohide" option).
If the client mounts such a tree, it is supposed to detect whenever it
crosses a mountpoint on the server, and bas
On Thu, 2005-02-10 at 10:00, Bryan Henderson wrote:
> >Don't you think, filesystems submitting biggest chunks of IO
> >possible is better than submitting 1k-4k chunks and hoping that
> >IO schedulers do the perfect job ?
>
> No, I don't see why it would better. In fact intuitively, I think the I
>Don't you think, filesystems submitting biggest chunks of IO
>possible is better than submitting 1k-4k chunks and hoping that
>IO schedulers do the perfect job ?
No, I don't see why it would better. In fact intuitively, I think the I/O
scheduler, being closer to the device, should do a better
>I am inferring this using iostat which shows that average device
>utilization fluctuates between 83 and 99 percent and the average
>request size is around 650 sectors (going to the device) without
>writepages.
>
>With writepages, device utilization never drops below 95 percent and
>is usually abo
On Wed, 2005-02-09 at 08:37, Stephen C. Tweedie wrote:
> Hi,
>
> On Wed, 2005-02-09 at 16:18, Badari Pulavarty wrote:
>
> > I am trying to understand journaling code in ext3.
> > Can some one enlighten me, why we need journal start
> > and stop in ext3_writeback_writepage() ? The block
> > alloc
When the lockfs patches went in an important bit got lost, the call in
generic_file_write to put newly incoming writers to sleep when a
filesystem is frozen. Nathan added back the call in the now separate
XFS write patch, and the patch for the generic code is below:
Index: mm/filemap.c
=
On Wed, 2005-02-09 at 18:05, Bryan Henderson wrote:
> >I see much larger IO chunks and better throughput. So, I guess its
> >worth doing it
>
> I hate to see something like this go ahead based on empirical results
> without theory. It might make things worse somewhere else.
>
> Do you have an e
On Thu, 2005-02-10 at 15:50 +0100, Christoph Hellwig wrote:
> On Thu, Feb 10, 2005 at 02:48:26PM +, Anton Altaparmakov wrote:
> > If the igrab() were not done, it would be possible for clear_inode to be
> > called on the 'parent' inode whilst at the same time one or more attr
> > inodes (belong
On Thu, Feb 10, 2005 at 02:50:02PM +, Anton Altaparmakov wrote:
> > If the igrab() were not done, it would be possible for clear_inode to be
> > called on the 'parent' inode whilst at the same time one or more attr
> > inodes (belonging to this 'parent') are in use and Bad Things(TM) would
> >
On Thu, 2005-02-10 at 14:48 +, Anton Altaparmakov wrote:
> On Thu, 2005-02-10 at 15:42 +0100, Christoph Hellwig wrote:
> > On Thu, Feb 10, 2005 at 02:40:39PM +, Anton Altaparmakov wrote:
> > > I am not sure what you mean. The VFS layer does reference counting on
> > > inodes. I have no ch
On Thu, Feb 10, 2005 at 02:48:26PM +, Anton Altaparmakov wrote:
> If the igrab() were not done, it would be possible for clear_inode to be
> called on the 'parent' inode whilst at the same time one or more attr
> inodes (belonging to this 'parent') are in use and Bad Things(TM) would
> happen..
On Thu, 2005-02-10 at 15:42 +0100, Christoph Hellwig wrote:
> On Thu, Feb 10, 2005 at 02:40:39PM +, Anton Altaparmakov wrote:
> > I am not sure what you mean. The VFS layer does reference counting on
> > inodes. I have no choice in the matter.
> >
> > > Can someone ever grab a reference sepa
On Thu, Feb 10, 2005 at 02:40:39PM +, Anton Altaparmakov wrote:
> I am not sure what you mean. The VFS layer does reference counting on
> inodes. I have no choice in the matter.
>
> > Can someone ever grab a reference separate from it's master inode?
>
> Again, not sure what you mean. Coul
On Thu, 2005-02-10 at 11:47 +0100, Christoph Hellwig wrote:
> On Thu, Oct 14, 2004 at 02:26:45PM +0100, Anton Altaparmakov wrote:
> > > I don't like filesystem doings things like this in ->put_inode at all,
> > > and indeed the plan is to get rid of ->put_inode completely. Why do
> > > you need to
Hi,
On Thu, 10 Feb 2005, Christoph Hellwig wrote:
> > affs already does it in a) and a few other places, so adding it to
> > affs_clear_inode should make it behave fine. Also move the truncate
> > from affs_put_inode with the racy i_count check to affs_clear_inode.
> > This also avoids the need
On Thu, Oct 14, 2004 at 02:26:45PM +0100, Anton Altaparmakov wrote:
> > I don't like filesystem doings things like this in ->put_inode at all,
> > and indeed the plan is to get rid of ->put_inode completely. Why do
> > you need to hold an additional reference anyway? What's so special
> > about t
On Sun, Dec 12, 2004 at 02:45:45PM +0100, Christoph Hellwig wrote:
> Currently affs discards preallocations in every ->put_inode but we
> really want to do this in
>
> a) ->release when a filedescriptor is closed and
> b) in ->clear_inode to avoid leaking reservations for shared writeable
>
34 matches
Mail list logo
