On Wed 21-11-12 13:44:05, Dave Chinner wrote:
> On Wed, Nov 21, 2012 at 02:48:51AM +0100, Jan Kara wrote:
> >
> > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> > index 51ea267..3e3422f 100644
> > --- a/fs/fs-writeback.c
> > +++ b/fs/fs-writeback.c
&g
e some different tag?
Honza
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/major
row.
Great, I wanted to have a look into it but you beat me to it ;)
Honza
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed 21-11-12 13:13:19, Darrick J. Wong wrote:
> On Wed, Nov 21, 2012 at 03:15:43AM +0100, Jan Kara wrote:
> > On Tue 20-11-12 18:00:56, Darrick J. Wong wrote:
> > > ext3 doesn't properly isolate pages from changes during writeback. Since
> > > the
> > >
On Fri 16-11-12 03:11:22, Marcus Sundman wrote:
> On 13.11.2012 15:51, Jan Kara wrote:
> >On Fri 09-11-12 15:12:43, Marcus Sundman wrote:
> >>On 09.11.2012 01:41, Marcus Sundman wrote:
> >>>On 07.11.2012 18:17, Jan Kara wrote:
> >>>>On Fri 02-11-12 04:
clear_page_dirty_for_io(p);
> + unlock_page(p);
> + }
> +
And this is wrong again for blocksize < pagesize. There can be other
dirty buffers under the page...
> /* We use-up our safety reference in submit_bh() */
>
> Free swap = 4883724kB
> Total swap = 4883724kB
> 524260 pages RAM
> 296958 pages HighMem
> 5221 pages reserved
> 406417 pages shared
> 351419 pages non-shared
>
> Does anyone have any debugging suggestions? Waiting overn
On Wed 21-11-12 17:47:55, Darrick J. Wong wrote:
> On Thu, Nov 22, 2012 at 08:47:13AM +1100, NeilBrown wrote:
> > On Wed, 21 Nov 2012 22:33:33 +0100 Jan Kara wrote:
> >
> > > On Wed 21-11-12 13:13:19, Darrick J. Wong wrote:
> > > > On Wed, Nov 21, 2012
On Thu 22-11-12 23:06:00, Jan Kara wrote:
> On Thu 22-11-12 12:58:24, George Spelvin wrote:
> > I'm having an interesting issue with a uniprocessor Pentium 4 machine
> > locking up overnight. 3.6.5 didn't do that, but 3.7-rc6 is not doing
> > so well.
> I
ibe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Jan Kara
SUSE Labs, CR
>From fd6
ize).
Top of the tree is 25389bb. The full shortlog is:
Jan Kara (1):
jbd: Fix lock ordering bug in journal_unmap_buffer()
The diffstat is
fs/jbd/transaction.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Tha
On Wed 09-01-13 15:26:43, Namjae Jeon wrote:
> 2012/12/13, Namjae Jeon :
> > 2012/10/19, Namjae Jeon :
> >> 2012/10/19, Jan Kara :
> >>> Hello,
> >>>
> >>> On Wed 10-10-12 00:10:01, Namjae Jeon wrote:
> >>>> From: Namjae Jeon
> Some code is from the patch of Kamal Mostafa.
The patch looks good. Thanks! You can add:
Reviewed-by: Jan Kara
BTW, since changes to filesystems are minimal, maybe Fengguang can take
the patch through his writeback tree? Fengguang?
er it seems as if some object
from previous page overflown into this page. I presume this was one time
event right? If it happens again please let us know. Also I can see you are
using SLUB in your config. If you happen to hit it again, try running with
SLAB whether the corruption will still happen...
On Sat 12-01-13 11:17:02, Wu Fengguang wrote:
> Patch looks good to me. But CC more people for review.
The patch looks fine to me as well. Feel free to add:
Reviewed-by: Jan Kara
> On Fri, Jan 11, 2013 at 01:06:37PM -0800, Tejun Heo wrote:
> > Add tracepoints for p
't need to sleep while holding
the lock and spinlocks are both faster and smaller...
> struct inode vfs_inode;
> };
>
> diff --git a/fs/udf/udfdecl.h b/fs/udf/udfdecl.h
> index de038da..db4a22e 100644
> --- a/fs/udf/udfdecl.h
> +++ b/fs/udf/udfdecl.h
> @@ -113,11 +113,6 @@
48 8b 3b e8 7f 9b af e0 0f b7 43 54 a8
> > [ 1384.754014] RIP [] udf_sb_free_partitions+0x71/0x140
> > [udf]
> > [ 1384.758925] RSP
> > [ 1384.763755] CR2: 0054
> > [ 1384.787502] ---[ end trace 95272ca777accb4e ]---
> >
> Hi James.
> There is mis
et = proc_dointvec(table, write, buffer, lenp, ppos);
> + if (!warned && block_dump) {
> + pr_warning("sysctl: vm.block_dump is scheduled for removal.
> Please use tracepoints instead.\n");
> + warned = true;
> + }
> + return ret;
> +}
>
> > Reported-by: James Hogan
> > Signed-off-by: Namjae Jeon
> > Signed-off-by: Ashish Sangwan
>
> v3.8-rc3 + your patch no longer crashes.
>
> Tested-by: James Hogan
Thanks for confirmation. I've added the fix to my tree and will push it
to Linus soon.
: Mark Fasheh
> From: Jan Kara
> Signed-off-by: Jan Kara
Darrick, to satisfy the kernel patch submission process you should also
add your Signed-off-by to the patch...
Honza
> ---
> fs/ocfs2/aops.c |1
gt; function. This should provide stable page write support to most filesystems,
> while eliminating unnecessary waiting for devices that don't require the
> feature.
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
>
work.
Signed-off-by: Jan Kara
---
kernel/printk.c | 54 +-
1 files changed, 49 insertions(+), 5 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 357f714..13a633f 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -246,9
tions(-)
Thanks
Honza
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kerne
On Wed 12-12-12 10:55:15, Shaohua Li wrote:
> 2012/12/11 Jan Kara :
> > Hi,
> >
> > I was looking into IO starvation problems where streaming sync writes (in
> > my case from kjournald but DIO would look the same) starve reads. This is
> > because reads h
On Wed 12-12-12 15:18:21, Dave Chinner wrote:
> On Wed, Dec 12, 2012 at 03:31:37AM +0100, Jan Kara wrote:
> > On Tue 11-12-12 16:44:15, Jeff Moyer wrote:
> > > Jan Kara writes:
> > >
> > > > Hi,
> > > >
> > > > I was
On Thu 13-12-12 09:43:31, Shaohua Li wrote:
> 2012/12/12 Jan Kara :
> > On Wed 12-12-12 10:55:15, Shaohua Li wrote:
> >> 2012/12/11 Jan Kara :
> >> > Hi,
> >> >
> >> > I was looking into IO starvation problems where streaming sync writes
ugh I/O. To address that, I think we need
> to move to a request list per io_context as Jan had suggested. That
> way, we can keep the logic about who gets to submit I/O when in one
> place.
>
> Jens, what do you think?
>
> Jan, for now, try bumping nr_requests up really high.
he allocation side, the assumption is that WRITE_SYNC behaves like
> dependent reads. Similar to a dd with oflag=direct, not like a flood of
> requests. For dependent sync writes, our current behaviour is fine, we
> treat them like reads. For commits of WRITE_SYNC, they should be treate
create a simple program simulating the writes and gather
'perf record' of the writer with commit=1 (so that we always hit the
problematic case) and commit=30 (so that it's rarely hit). And the we could
compare the reports...
-off-by: Darrick J. Wong
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> Documentation/ABI/testing/sysfs-class-bdi |5 +
> block/blk-integrity.c |4
>
gt; +void wait_for_stable_page(struct page *page)
> +{
> + struct address_space *mapping = page_mapping(page);
> + struct backing_dev_info *bdi = mapping->backing_dev_info;
> +
> + if (!bdi_cap_stable_pages_required(bdi))
> + return;
> +
> + wait_on_page_writeback(page);
> +}
> +EXPORT_SYMBOL_GPL(wait_for_stable_page);
>
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
20,6 +620,7 @@ v9fs_vm_page_mkwrite(struct vm_area_struct *vma, struct
> vm_fault *vmf)
> lock_page(page);
> if (page->mapping != inode->i_mapping)
> goto out_unlock;
> + wait_for_stable_page(page);
>
> return
} else {
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index 3e4a8cc..fbd8efb 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2291,6 +2291,10 @@ void wait_for_stable_page(struct page *page)
>
> if (!bdi_cap_stable_pages_required(bdi))
&
deletions(-)
Thanks
Honza
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
On Thu 27-09-12 00:56:02, Wu Fengguang wrote:
> On Tue, Sep 25, 2012 at 12:23:06AM +0200, Jan Kara wrote:
> > On Thu 20-09-12 16:44:22, Wu Fengguang wrote:
> > > On Sun, Sep 16, 2012 at 08:25:42AM -0400, Namjae Jeon wrote:
> > > > From: Namjae Jeon
> >
On Thu 27-09-12 15:00:18, Namjae Jeon wrote:
> 2012/9/27, Jan Kara :
> > On Thu 27-09-12 00:56:02, Wu Fengguang wrote:
> >> On Tue, Sep 25, 2012 at 12:23:06AM +0200, Jan Kara wrote:
> >> > On Thu 20-09-12 16:44:22, Wu Fengguang wrote:
> >> > > On Sun,
which fails is:
BUG_ON(!list_empty(&bh->b_assoc_buffers));
Now b_assoc_buffers isn't used very much. In particular ext4 which you seem
to be using doesn't use this list at all (except when mounted in nojournal
mode but that doesn't seem to be your case). That would poi
On Thu 27-09-12 17:46:48, Alexander Holler wrote:
> Hello,
>
> Am 27.09.2012 17:12, schrieb Jan Kara:
> > Just some thoughts about your oops:
> >The assertion which fails is:
> >BUG_ON(!list_empty(&bh->b_assoc_buffers));
> >
> >Now b_assoc_buffers
This last message usually means hardware really has an issue. You can
use mcelog tool to find out what problems did the hardware report.
Honza
--
Jan Kara
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe l
On Sat 29-09-12 21:07:27, Alexander Holler wrote:
> Am 27.09.2012 22:03, schrieb Jan Kara:
> >On Thu 27-09-12 17:46:48, Alexander Holler wrote:
> >>Hello,
> >>
> >>Am 27.09.2012 17:12, schrieb Jan Kara:
> >>> Just some thoughts about your oops
). So pagecache page is writeable
if and only if it is dirty.
CC: Martin Schwidefsky
CC: Mel Gorman
CC: linux-s...@vger.kernel.org
Signed-off-by: Jan Kara
---
mm/rmap.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 0f3b7cd..6c
page that has a valid mapping, decide whether or
> + * not we have to employ bounce buffering to guarantee stable pages.
> + */
> + bio_for_each_segment(from, bio, i) {
> + page = from->bv_page;
> + mapping = page_mapping(page);
> + if (!ma
oper tracepoints are in place, vm.block_dump isn't
> necessary. Generate a warning if used so that it can be removed down
> the road.
>
> Cc: Added contact info as suggested by Jan.
>
> Signed-off-by: Tejun Heo
> Cc: Jan Kara
Thanks. The pat
On Tue 15-01-13 23:37:42, Andrew Morton wrote:
> On Tue, 15 Jan 2013 18:58:34 +0100 Jan Kara wrote:
>
> > A CPU can be caught in console_unlock() for a long time (tens of seconds are
> > reported by our customers) when other CPUs are using printk heavily and
> >
kernel thread is a pretty radical change
> - it surely adds significant risk that output will be lost.
I agree there is a higher chance the output will be lost.
> So hrm, I dunno. Can we just put the touch_nmi_watchdog() in there
> intially, see if it fixes things? If people continue to
have to employ bounce buffering to guarantee stable pages.
> > > + */
> > > + bio_for_each_segment(from, bio, i) {
> > > + page = from->bv_page;
> > > + mapping = page_mapping(page);
> > > + if (!mapping)
> > > +
On Wed 16-01-13 16:11:18, Andrew Morton wrote:
> On Thu, 17 Jan 2013 00:55:29 +0100
> Jan Kara wrote:
> > > If this is all a problem then the calling code should stop doing so
> > > much printing!
> > It's mostly a device discovery that triggers the iss
On Thu 17-01-13 13:39:17, Andrew Morton wrote:
> On Thu, 17 Jan 2013 22:04:42 +0100
> Jan Kara wrote:
>
> > ...
> >
> > So I played a bit with this. To make things easier for me I added
> > artificial mdelay(len*10) (effectively simulating console able to pr
unt -o remount,rw /
But with the patch, the quotas will be turned off. So I'm not sure
whether it's acceptable as a -stable thing...
Honza
>
> ------
>
>
> From: Jan Kara
have a look what we can do.
> udf_add_entry() defines a couple of 256-byte local arrays.
Yes, exactly two of them. One is non-trivial to get rid of - it's
used for encoding of filename before we write it, but one is used during
scanning of the directory whether the entry doesn't alre
ing on complete
> removal of one of those fields ... ?
Yes, I'll convert one variable to kmalloc and the other one remove
completely. Stay tuned ;).
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "u
nt here,
> we can further check more on this.
Well, at least we know changing the condition has unexpected side
effects. I'd like to understand those before discarding the idea - because
in your setup flusher thread must end up writing rather small amount of
pages in each run when it's running continuously and
Hello.
> Perhaps the help text for disk quotas needs to be updated, or at least the
> howto for quotas.
>
> The help text for disk quotas says to see the Quota mini-HOWTO. The howto
> says to get the quota source from:
>
> ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/subsystems/quota/all.tar.gz
Hello.
So I've updated my quota patches for 2.4.0-prerelease. I also
fixed one locking bug in implementation of new quotafile format
and added a few comments. I also fixed compilation problems
(when quota was disabled) - Alan, were there any problems
I didn't fix (I've seen you and someone el
> When running 'quotaon -a' I get message 'quotaon: using /quota.user on
> /dev/hdc3: Invalid argument'. This occurs at least with 2.4.0-ac4 and
> 2.4.0-ac9, but not with 2.4.0.
That's because 2.4.0-ac? supports new quota format which is incompatible
with the old one... You need also new utili
Hello.
I'm sending you a small fix in quota. Currently on
systems with many different users there are problems that too
many dquots are bound in unused inodes. Following patch
fixes it - quota tries to get dquots from unused inodes
more than once.
Hello.
After rewrite of umount checks some time ago (just now reading your mail
I realized I never asked) filesystem doesn't umount when quotas are
turned on on it - it fails on check (atomic_read(&mnt->mnt_count) > 2)
in do_umount().
Is this intended behaviour? If so, we can remove later D
Hello.
> --- fs/super.c Thu Nov 2 22:38:59 2000
> +++ fs/super.c.new Tue Nov 21 11:36:05 2000
> @@ -1037,13 +1037,13 @@
> }
>
> spin_lock(&dcache_lock);
> - if (atomic_read(&mnt->mnt_count) > 2) {
> - spin_unlock(&dcache_lock);
> - mntput(
Hello.
> After installing and configuring kernel 2.4.0-test11, all is working well,
> except quota's on the root FS. I am at a loss as to how to correct this:
>
> ls -l /quota.*
> ls: /quota.group: Value too large for defined data type
> ls: /quota.user: Value too large for defined data type
Hello.
After rewrite on umount code automagical turning of
quotas off stopped working - filesystem was considered
busy.
I would restore the behaviour in 2.4 and probably
in 2.5 move this to userland together with other quota
changes...
Following patch (written by Al Viro) should restore
t
> On 14 Nov 00 at 18:39, Jan Kara wrote:
> > Hello.
> >
> > > On 9 Nov 00 at 19:18, Jan Kara wrote:
> > > > used (I tried to contact Ulrich Drepper <[EMAIL PROTECTED]> who should
> > > > be right person to ask about such things (at l
Hello.
> On 9 Nov 00 at 19:18, Jan Kara wrote:
> > used (I tried to contact Ulrich Drepper <[EMAIL PROTECTED]> who should
> > be right person to ask about such things (at least I was said so) but go
> > no answer...). Does anybody have any better solution?
&g
Hello.
Following patch against 2.4.0-test7 does a small cleanup in ext2/ialloc.c.
ext2_new_inode() now initializes quota on inode - I think this is more error
proof than initializing quota all over the place. Now it also uses DQUOT_DROP()
macro (which is usual way) instead of direct function
Hello.
Following patch against 2.4.0-test7 fixes returning of errors from
ext2_new_inode(). Currenly if ext2_new_inode() failed EIO was returned
from functions like ext2_create() which is bad as it can fail also
with EDQUOT and such.
Ho
Hello.
Following patch fixes bug in dquot_transfer() - while we were sleeping
i_blocks might change and so number quota was miscounted. Patches are
against 2.2.16 and 2.4.0-test6 (but should apply well on newer versions).
Honza
--- l
> On Mon, 4 Sep 2000, Jan Kara wrote:
>
> > Hello.
> >
> > Following patch fixes bug in dquot_transfer() - while we were sleeping
> > i_blocks might change and so number quota was miscounted. Patches are
> > against 2.2.16 and 2.4.0-test6 (but
> > of blocks after notify_change() once more all the quota will be counted
> > properly. The only problem is that quota can be exceeded this way. We have to check
>
> Nope. You've just shifted the race window (and inverted the
> effect) - think what happens if you've got new allocations af
> How about the following:
> * dquot_{alloc,free}_block() _never_ blocks.
> * we have 3 inlined helper functions - alloc_block(), free_block() and
> change_xid(). They get exclusion (BKL, spinlock, whatever) and update both
> quota and i_blocks.
>
> Consequences:
> * quota for f
Hello.
I found one bug in the quota fixes (forgot to mark_inode_dirty()
when i_blocks were changed). Patch which fixes this is at:
ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/quota-fix-2.4.0-test9-2a.diff
It's supposed to be applied after quota-fix-2.4.0-test9-1.diff in the sa
Hello.
> > "Stephen C. Tweedie" wrote:
> > >
> > > Hi Jan,
> > >
> > > On Wed, Sep 27, 2000 at 02:56:20PM +0200, Jan Kara wrote:
> > > >
> > > > So I've been thinking about fixes in quota (and also writing s
Hello.
> Running with 2.2.17
> VFS: Diskquotas version dquot_6.4.0 initialized
>
> We have some problem with the quota with only SOME users.
> Is there any new version of quota which fix this kind of
> bug ?
>
> #cat /etc/fstab | grep home
> /dev/rd/c0d0p7 /home ext2defaults,usrquota
Hello.
I've got a report that some people using quotas for lots of
users are experiencing being out of dquots. The problem is
that we have quota structs bound in unused inodes and we are not
aggressive enough to get it back. The following patch should
fix it (OK, more proper would be to make
Hello.
I've ported my quota patches for 2.4.0-test12.
You can download the patches from
ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/
quota-fix-2.4.0-test12-1.diff.gz
and
quota-patch-2.4.0-test12-1.diff.gz
Honza
-
To unsubscribe from this
> I've ported my quota patches for 2.4.0-test12.
> You can download the patches from
> ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/
> quota-fix-2.4.0-test12-1.diff.gz
> and
> quota-patch-2.4.0-test12-1.diff.gz
Sorry to follow up myself. I had better tell what those patches do :-):
>
> On Mon, 11 Sep 2000, Martin Diehl wrote:
>
> > transfer_to[cnt] is initialized to NODQUOT from the first loop
> > (due to several continue's e.g.) when entering the second loop.
> > Unfortunately I do not feel familiar enough to the quota code to
> > provide a patch for this problem.
>
> we
Hello.
So I did the fixes of races in quota Al found. The patch can
be found at
ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/quota-fix-2.4.0-test8-1.diff.
In the patch are included also some cleanups (especially change in
invalidate_dquots()) which I originally wanted to leave
Hello.
So I've been thinking about fixes in quota (and also writing some parts).
I think I thought of a bit easier implementation of featureas Al suggested. So:
* i_blocks is updated by quota in DQUOT_{ALLOC|FREE}_BLOCK (as a bonus we get
fix of those unpleasant ext2 preallocation vs.
Hello.
I've updated the patch with quota fixes for test9. You can download
it at: ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4 as
quota-fix-2.4.0-test9-1.diff
If nobody complains I'll submit it to Linus so please test.
Honz
Hello.
>I maintain quotatool, a command-line quota utility.
> Right now, I'm using BLOCK_SIZE -- defined in
> -- to convert between blocks and bytes.
> I'd like to not use the linux header files at all for
> this, but how else can I find the info?
In current kernel there's no constant sp
> I get OOPs in log_do_checkpoint() while using ext3 quotas.
> Is this anyway related to what you are working on ?
Nope, it does not seem to be the same problem. In theory it could be a
bug Stephen fixed some time ago - could you try to reproduce the problem
with 2.6.12-rc2 (it contains the fix)
Hello,
> On Mon, 2005-04-04 at 10:04, Jan Kara wrote:
>
> > In log_do_checkpoint() we go through the t_checkpoint_list of a
> > transaction and call __flush_buffer() on each buffer. Suppose there is
> > just one buffer on the list and it is dirty. __flush_buffer() se
ange it.
I can't think of any problems which can be with it... Your patch seems to be fine.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
Hello,
> Alan pointed out that you're still the maintainer for the 2.2 quota
> code, so I'm forwarding this patch to you as well as the earlier 2.4
> patch.
The patch seems fine (although I can't quite understand those double -
in it :)).
I
think.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.htm
lure later when transaction is dropped). The patch is
against 2.6.13-rc2 kernel. The race was really happening to David Wilk
<[EMAIL PROTECTED]> (thanks for testing) so please apply if you find
the patch correct.
Honza
--
e old
ll_rw_block()'s behaviour makes this impossible to achieve (as in some
places we lock and unlock buffer without sending it to disk). The patch
also changes the one caller in buffer.c. Please apply.
Honza
--
Jan Kara <[EMAIL PROTEC
Hello,
attached patch changes ll_rw_block() calls in Reiserfs to make sure
that submitted data really reach the disk (the patch relies on the
previous ll_rw_block() patch).
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR L
Hi,
attached patch changes HFS+ to use sync_one_buffer() instead of
ll_rw_block() and wait_on_buffer().
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
Use block layer predefined function.
Signed-off-by: Jan Kara &
Hi,
attached patch changes UFS to use SWRITE when sending data to disk in
O_SYNC mode. Please apply.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
We need to be sure that current data are sent to disk. Hence w
to be journaled we either finish the pending write-out
before attaching a buffer to a transaction or we won't write the buffer
until the transaction is going to be committed... Please apply.
Honza
--
Jan Kara <[EMAIL PROTECTED]
Hi,
attached patch changes calls of ll_rw_block() in JBD to make sure the
data really reach the disk.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
We must be sure that the current data in buffer are sent to disk.
Hello,
> On Mon, 2005-07-11 at 17:10, Jan Kara wrote:
>
> > attached patch should fix the following race:
> ...
> > and we have sent wrong data to disk... We now clean the dirty buffer
> > flag under buffer lock in all cases and hence we know that whenever a b
Looks fine. Giving CC to Andrew to queue it for inclusion. Andrew,
can you please also add
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
Thanks
Honza
> This patch
quota format but the
journaled and the unjournaled quota...
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
Hi,
> I just applied the patch submitted by Jan Kara:
> http://bugzilla.kernel.org/show_bug.cgi?id=4771#c3
> I dont know yet if it solves the problem :)
I actually should cure your problem but can have some unexpected
sideffects. Please try an attached patch (it's the new on
not, but it does require
> acl to be enabled.
This seems to be the same problem as bug #4771 that I've just fix. Can
you try attached patch please?
Andrew, can you include the patch into -mm if ReiserFS guys won't object?
Honza
--
Jan Kara <[EMAIL
to reproduce the hang. My fault, your bug is a different
problem. Now it hangs also for me so I can debug it :)
Honza
> On K, 2005-08-10 at 15:00 +0200, Jan Kara wrote:
> > Hello,
> >
> > > I've already
Hi,
the patch below fixes oops triggered when user exceeded his inode
quota on reiserfs (reiserfs incorrectly thought the inode has been
already allocated and tried to free it). Please apply.
Honza
--
Jan Kara <[EM
's fix). Attached patch should fix it.
Honza
> On K, 2005-08-10 at 15:00 +0200, Jan Kara wrote:
> > Hello,
> >
> > > I've already reported a similiar bug to the one I found now
> > > and that wa
> + case Opt_grpquota:
> + set_opt(sbi->s_mount_opt, GRPQUOTA);
> + break;
> +
> + case Opt_quota:
> + set_opt(sbi->s_mount_opt, GRPQUOTA);
> + set_opt(sbi->s_mount_opt, USRQUOTA);
> +
501 - 600 of 3571 matches
Mail list logo
