xfs
[Top] [All Lists]

Re: page_buf breakage...

To: Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: page_buf breakage...
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Wed, 12 Jul 2000 17:33:17 -0500
Cc: linux-xfs@xxxxxxxxxxx
References: <200007120635.QAA65636@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
Daniel Moore wrote:

Try this patch and see how things work for you...
I still have debugging messages in... you may want to take them out.
I haven't testing this a bunch but it does correctly update the size.
Note I assume you are running with kiobufs turned on?
I'm not sure if the none kiobuf path is broken... I'll look at that
later tonight.

> Russell Cattelan writes:
>  => Daniel Moore wrote:
>  => > Is pb_count_desired meant to be supported or is it an IRIX hang
>  => > over that needs to be removed?
>  =>
>  => Hmm... well we need to write out the correct number of bytes.
>  => Let me look at this and see if we should change xfs or pagebuf...
>
> XFS_BUF_SET_COUNT is the only writer of pb_count_desired in XFS.
> xlog_bwrite is the only user of XFS_BUF_SET_COUNT in XFS.
> xlog_bwrite is local to xfs_log_recover.c
>
>  => Where in pagebuf is it ignoring the count field?
>
> I think all the time - there seems to be an assumption that
> pb_count_desired == pb->pb_buffer_length or perhaps that it's
> a rounded up version of pb_buffer_length (not sure).
>
> The log recovery code seems to be the only code that allocates
> a buffer of size X and then requests (through pb_count_desired)
> that only Y bytes get written (where Y<X).
>
> Pagebuf writing the whole lot is ok most of the time until you
> try to mount when the log head is close to the end of the log,
> then the big write goes outside the log and clobbers stuff.
>
> -----------------------------------------------------
>  Daniel Moore                  dxm@xxxxxxx
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------
--- /usr/tmp/TmpDir.16510-0/linux/fs/pagebuf/page_buf.c_1.10    Wed Jul 12 
17:29:52 2000
+++ linux/fs/pagebuf/page_buf.c Wed Jul 12 17:18:49 2000
@@ -1935,7 +1935,8 @@
        int status = 0;
        int sval;
        loff_t buffer_offset = pb->pb_file_offset;
-       size_t buffer_len = pb->pb_buffer_length;
+//     size_t buffer_len = pb->pb_buffer_length;
+       size_t buffer_len = pb->pb_count_desired;
        size_t page_offset;
        size_t len;
        size_t total = 0;
@@ -1957,7 +1958,7 @@
                panic("pb offset/length unaligned!");
        }
 #endif
-
+       printk("pagebuf_segment_apply length:%ld 
count:%ld\n",pb->pb_buffer_length,pb->pb_count_desired);
        pagebuf_hold(pb);
        for (vec_index = 0; vec_index < pb->pb_mem.pba_kiocnt; vec_index++) {
                if (buffer_len == 0)
@@ -1978,7 +1979,8 @@
                         * Lets see if I'm wrong.
                         * -Chait.
                         */
-                       cur_len = buffer_len;
+                       cur_len = kb->length = buffer_len;
+                       printk("pagebuf_segment_apply count changed reseting 
kiovec to %ld\n",cur_len);
                        /*
                         * So, if we decide to unilaterally modify the amount
                         * of I/O done thus, then kb->length would be invalid!
@@ -1987,7 +1989,7 @@
                         * against this kiobuf.
                         * -Chait.
                         */
-                       BUG();
+/*                     BUG(); */
                }
 #if CONFIG_KIOBUF_IO
                /* Works for scsi-disks, else get back -ENOSYS */
<Prev in Thread] Current Thread [Next in Thread>