From: Boaz Harrosh <bharrosh@panasas.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
open-osd <osd-dev@open-osd.org>
Subject: [GIT PULL] exofs fixes for 2.6.33-rc3
Date: Wed, 06 Jan 2010 11:31:41 +0200 [thread overview]
Message-ID: <4B44587D.30503@panasas.com> (raw)
Linus please pull:
git://git.open-osd.org/linux-open-osd.git for-linus
To receive the following two fixes for the 2.6.33 Kernel.
. The first problem was found when integrating pnfs-tree with 2.6.33-rc1
. The second problem was found by running a git-clone of a very large Linux tree
on a memory tight system, with these new very large pack files of recent. Actually
I think only git clone is able to produce a workload to exercise this bug.
(up until now git has found 85% of my bugs it's my number one test. Other 15% is
compilation of a kernel, all the synthetic tests are good for nothing)
commit 89be503021f550575fc896671b569941140b2c2e
Author: Boaz Harrosh <bharrosh@panasas.com>
Date: Mon Dec 21 16:36:23 2009 +0200
exofs: fix pnfs_osd re-definitions in pre-pnfs trees
Some on disk exofs constants and types are defined in the pnfs_osd_xdr.h
file. Since we needed these types before the pnfs-objects code was
accepted to mainline we duplicated the minimal needed definitions into
an exofs local header. The definitions where conditionally included
depending on !CONFIG_PNFS defined. So if PNFS was present in the tree
definitions are taken from there and if not they are defined locally.
That was all good but, the CONFIG_PNFS is planed to be included upstream
before the pnfs-objects is also included. (The first pnfs batch might be
pnfs-files only)
So condition exofs local definitions on the absence of pnfs_osd_xdr.h
inclusion (__PNFS_OSD_XDR_H__ not defined). User code must make sure
that in future pnfs_osd_xdr.h will be included before fs/exofs/pnfs.h,
which happens to be so in current code.
Once pnfs-objects hits mainline, exofs's local header will be removed.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
fs/exofs/pnfs.h | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
commit efd124b999fb4d426b30675f1684521af0872789
Author: Boaz Harrosh <bharrosh@panasas.com>
Date: Sun Dec 27 17:01:42 2009 +0200
exofs: simple_write_end does not mark_inode_dirty
exofs uses simple_write_end() for it's .write_end handler. But
it is not enough because simple_write_end() does not call
mark_inode_dirty() when it extends i_size. So even if we do
call mark_inode_dirty at beginning of write out, with a very
long IO and a saturated system we might get the .write_inode()
called while still extend-writing to file and miss out on the last
i_size updates.
So override .write_end, call simple_write_end(), and afterwords if
i_size was changed call mark_inode_dirty().
It stands to logic that since simple_write_end() was the one extending
i_size it should also call mark_inode_dirty(). But it looks like all
users of simple_write_end() are memory-bound pseudo filesystems, who
could careless about mark_inode_dirty(). I might submit a
warning-comment patch to simple_write_end() in future.
CC: Stable <stable@kernel.org>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
fs/exofs/inode.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
Thanks in advance
Boaz
reply other threads:[~2010-01-06 9:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4B44587D.30503@panasas.com \
--to=bharrosh@panasas.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=osd-dev@open-osd.org \
--cc=torvalds@linux-foundation.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 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.