I plan to test the persistent preallocation patches on a huge sparse
device, to know if >32 bit physical block numbers (upto 48bit) behave as
expected. I have following questions for this and will appreciate
suggestions here:
a) What should be the sparse device size which I should use for testing?
On Tue, Feb 06, 2007 at 03:50:01PM -0800, Andrew Morton wrote:
> On Tue, 6 Feb 2007 14:23:33 +0100
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > static void add_dquot_ref(struct super_block *sb, int type)
> > {
> > - struct list_head *p;
> > + struct inode *inode;
> >
> > restart:
Andrew Morton wrote:
On Tue, 16 Jan 2007 21:05:20 +0900
[EMAIL PROTECTED] wrote:
...
+ext4_ext_replace_branches(struct inode *org_inode, struct inode *dest_inode,
+ pgoff_t from_page, pgoff_t dest_from_page,
+ pgoff_t count_page, unsigned long *delete_start)
+{
+
On Wed, Feb 07, 2007 at 09:58:57AM +1100, David Chinner wrote:
> On Tue, Feb 06, 2007 at 09:02:01AM +0100, Nick Piggin wrote:
> > Still no independent confirmation as to whether this is a problem or not.
> > I think it is, so I'll propose this patchset to fix it. Patch 1/3 has a
> > reasonable desc
On Mon, 5 Feb 2007 14:12:04 +0100
Jan Kara <[EMAIL PROTECTED]> wrote:
> > Move the blocks on the temporary inode to the original inode
> > by a page.
> > 1. Read the file data from the old blocks to the page
> > 2. Move the block on the temporary inode to the original inode
> > 3. Write the file d
On Tue, 16 Jan 2007 21:05:20 +0900
[EMAIL PROTECTED] wrote:
> Move the blocks on the temporary inode to the original inode
> by a page.
> 1. Read the file data from the old blocks to the page
> 2. Move the block on the temporary inode to the original inode
> 3. Write the file data on the page into
On Tue, 6 Feb 2007 14:23:33 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> static void add_dquot_ref(struct super_block *sb, int type)
> {
> - struct list_head *p;
> + struct inode *inode;
>
> restart:
> - file_list_lock();
> - list_for_each(p, &sb->s_files) {
> -
On Tue, 06 Feb 2007 11:33:46 +0300
Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
> Almost all read/write operation handles data with chunks(segments or pages)
> and result has integral behaviour for folowing scenario:
> for_each_chunk() {
> res = op();
> if(IS_ERROR(res))
>
On Tue, Feb 06, 2007 at 09:02:01AM +0100, Nick Piggin wrote:
> Still no independent confirmation as to whether this is a problem or not.
> I think it is, so I'll propose this patchset to fix it. Patch 1/3 has a
> reasonable description of the problem.
>
Nick, can you include a diffstat at the hea
Folks,
I'm not sure of the exact locking rules and constraints for
->page_mkwrite(), so I thought I better fish around for comments.
With XFS, we need to hook pages being dirtied by mmap writes so that
we can attach buffers of the correct state tothe pages. This means
that when we write them bac
Tony Jones wrote:
> The following are a set of patches the goal of which is to pass vfsmounts
> through select portions of the VFS layer sufficient to be visible to the LSM
> inode operation hooks.
I was looking forward to these patches for so long.
Chris Wright wrote:
> This kind of change (or pe
On Tue, 2007-02-06 at 03:09 +0100, Nick Piggin wrote:
> On Sun, Feb 04, 2007 at 05:40:35PM +, Anton Altaparmakov wrote:
> > On Sun, 4 Feb 2007, Andrew Morton wrote:
> > > truncate's OK: we're holding i_mutex.
> >
> > How about excluding readpage() (in addition to truncate if Nick is right
>
On Tue 06-02-07 14:23:33, Christoph Hellwig wrote:
> Iterate over sb->s_inodes instead of sb->s_files in add_dquot_ref.
> This reduces list search and lock hold time aswell as getting rid of
> one of the few uses of file_list_lock which Ingo identified as a
> scalability problem.
>
> Previously we
Iterate over sb->s_inodes instead of sb->s_files in add_dquot_ref.
This reduces list search and lock hold time aswell as getting rid of
one of the few uses of file_list_lock which Ingo identified as a
scalability problem.
Previously we called dq_op->initialize for every inode handing of
a writeabl
On Mon, 2007-02-05 at 18:13 -0800, Andreas Gruenbacher wrote:
> On Monday 05 February 2007 10:44, Christoph Hellwig wrote:
> > Looking at the actual patches I see you're lazy in a lot of places.
> > Please make sure that when you introduce a vfsmount argument somewhere
> > that it is _always_ passe
On Mon 05-02-07 19:05:27, Christoph Hellwig wrote:
> Remove_dquot_ref can move to dqout.c instead of beeing in inode.c
> under #ifdef CONFIG_QUOTA. Also clean the resulting code up
Yes, this was because at the time the code was written, inode_lock was not
exported
from inode.c.
> a tiny little
On Tue, Feb 06, 2007 at 09:26:14PM +1100, Neil Brown wrote:
> What would be the benefit of having private non-visible vfsmounts?
> Sounds like a recipe for confusion?
>
> It is possible that mountd might start doing bind-mounts to create the
> 'pseudo filesystem' thing for NFSv4, but they would be
On Tuesday February 6, [EMAIL PROTECTED] wrote:
> On Tue, Feb 06, 2007 at 12:51:52AM -0800, Trond Myklebust wrote:
> > Who cares? There is no way to export a partial directory, and in any
> > case the subtree_check crap is borken beyond repair (see cross-directory
> > renames which lead to actual c
On Tuesday February 6, [EMAIL PROTECTED] wrote:
> On Mon, Feb 05, 2007 at 07:20:35PM -0800, Andreas Gruenbacher wrote:
> > It's actually not hard to "fix", and nfsd would look a little less weird.
> > But
> > what would this add, what do pathnames mean in the context of nfsd, and
> > would
> >
On Mon, Feb 05, 2007 at 06:13:26PM -0800, Andreas Gruenbacher wrote:
> On Monday 05 February 2007 10:44, Christoph Hellwig wrote:
> > Looking at the actual patches I see you're lazy in a lot of places.
> > Please make sure that when you introduce a vfsmount argument somewhere
> > that it is _always
On Tue, Feb 06, 2007 at 12:51:52AM -0800, Trond Myklebust wrote:
> Who cares? There is no way to export a partial directory, and in any
> case the subtree_check crap is borken beyond repair (see cross-directory
> renames which lead to actual changes to the filehandle - broken, broken,
> broken)
On Mon, Feb 05, 2007 at 07:20:35PM -0800, Andreas Gruenbacher wrote:
> It's actually not hard to "fix", and nfsd would look a little less weird. But
> what would this add, what do pathnames mean in the context of nfsd, and would
> nfsd actually become less weird?
It's not actually a pathname we
On Mon, Feb 05, 2007 at 10:17:44PM -0500, Theodore Tso wrote:
> > sysrq+u is helpful. It is like \( sysrq+s && make sure no further writes
> > go to disk \).
>
> I agree it is useful, but if we're going to do it we really should do
> it right. We should have real revoke() functionality on file
>
Andrew Morton wrote:
On Tue, 6 Feb 2007 09:02:11 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote:
+static inline void __SetPageUptodate(struct page *page)
+{
+#ifdef CONFIG_S390
if (!test_and_set_bit(PG_uptodate, &page->flags))
page_test_and_clear_dirty(page);
-}
#el
On Tue, Feb 06, 2007 at 12:28:39AM -0800, Andrew Morton wrote:
> >
> > Also, a memory leak in sys_swapon().
>
> Separate patch?
Gack, I'm an idiot, there is no memory leak :P
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Andrew Morton wrote:
On Tue, 6 Feb 2007 09:02:33 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote:
Ensure pages are uptodate after returning from read_cache_page, which allows
us to cut out most of the filesystem-internal PageUptodate_NoLock calls.
Normally it's good to rename functions w
On Mon, 2007-02-05 at 19:20 -0800, Andreas Gruenbacher wrote:
> On Monday 05 February 2007 11:02, Christoph Hellwig wrote:
> > On Mon, Feb 05, 2007 at 10:58:26AM -0800, Trond Myklebust wrote:
> > > On Mon, 2007-02-05 at 18:44 +, Christoph Hellwig wrote:
> > > > Just FYI: Al was very opposed to
This patch solve ext3/4 retry loop issue
Issue description:
What we can do if block_prepare_write fail inside ext3_prepare_write ?
a) Stop transaction and do retry if possible, but what happend if
reboot comes after journal_force_commit, but before we exhaust
all retry attempts and generic_
Almost all read/write operation handles data with chunks(segments or pages)
and result has integral behaviour for folowing scenario:
for_each_chunk() {
res = op();
if(IS_ERROR(res))
return progress ? progress : res;
progress += res;
}
prepare_write may has integral be
On Tue, Feb 06, 2007 at 12:21:40AM -0800, Andrew Morton wrote:
> On Tue, 6 Feb 2007 09:02:23 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]>
> wrote:
>
> > __block_write_full_page is calling SetPageUptodate without the page locked.
> > This is unusual, but not incorrect, as PG_writeback is still set
On Tue, 6 Feb 2007 09:02:33 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote:
> Ensure pages are uptodate after returning from read_cache_page, which allows
> us to cut out most of the filesystem-internal PageUptodate_NoLock calls.
Normally it's good to rename functions when we change their beh
On Tue, 6 Feb 2007 09:02:11 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote:
> +static inline void __SetPageUptodate(struct page *page)
> +{
> +#ifdef CONFIG_S390
> if (!test_and_set_bit(PG_uptodate, &page->flags))
> page_test_and_clear_dirty(page);
> -}
> #else
> -#define
On Tue, 6 Feb 2007 09:02:23 +0100 (CET) Nick Piggin <[EMAIL PROTECTED]> wrote:
> __block_write_full_page is calling SetPageUptodate without the page locked.
> This is unusual, but not incorrect, as PG_writeback is still set.
>
> However with the previous patch, this is now a problem: so don't bo
Ensure pages are uptodate after returning from read_cache_page, which allows
us to cut out most of the filesystem-internal PageUptodate_NoLock calls.
I didn't have a great look down the call chains, but this appears to fixes 7
possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in e
__block_write_full_page is calling SetPageUptodate without the page locked.
This is unusual, but not incorrect, as PG_writeback is still set.
However with the previous patch, this is now a problem: so don't bother
setting the page uptodate in this case (it is weird that the write path
does such a
After running SetPageUptodate, preceeding stores to the page contents to
actually bring it uptodate may not be ordered with the store to set the page
uptodate.
Therefore, another CPU which checks PageUptodate is true, then reads the
page contents can get stale data.
Fix this by ensuring SetPageUp
Still no independent confirmation as to whether this is a problem or not.
I think it is, so I'll propose this patchset to fix it. Patch 1/3 has a
reasonable description of the problem.
Thanks,
Nick
--
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the bod
37 matches
Mail list logo
