Hello,
On Thu 21-02-08 13:58:55, Josef Bacik wrote:
This is related to that jbd patch I sent a few weeks ago. I originally
found that the problem where t_nr_buffers would be than
t_outstanding_credits wouldn't happen upstream, but apparently I'm an
idiot and I was just missing my
Hi all,
Currently, I have a big problem: e2fsck refuses to fix my currupted
filesystem...
The filesystem (about 3TB) is created on an LVM LV, which spans a number
of RAID5 arrays, for which the underlying devices are imported using ATA
over Ethernet. Because of some strange network failure, the
Theodore Tso wrote:
On Fri, Feb 22, 2008 at 01:07:13PM +0100, Bas van Schaik wrote:
Hi all,
Currently, I have a big problem: e2fsck refuses to fix my currupted
filesystem...
The things that I would suggest first of all is upgrading to the
latest version of e2fsprogs. If that
On Thu, Feb 21, 2008 at 04:10:17PM -0600, Eric Sandeen wrote:
This is for RH Bugzilla #433857:
rpc.mountd segfaults due to uninitialized value in e2fsprogs devname.c
https://bugzilla.redhat.com/show_bug.cgi?id=433857
which did some very helpful analysis provided a patch.
This patch is
A write to prealloc area cause the split of unititalized extent into a
initialized
and uninitialized extent. If we don't have space to add new extent information
instead
of returning error convert the existing uninitialized extent to initialized
one. We
need to zero out the blocks corresponding
Put the old extent details back if we fail to split the
uninitialized extent.
Signed-off-by: Aneesh Kumar K.V [EMAIL PROTECTED]
---
fs/ext4/extents.c | 26 --
1 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index
Theodore Tso wrote:
This looks good, but I assume that the bug was caused by some race
condition where if you try to call dm_task_get_info() while some other
process is creating or removing a snapshot, dm_task_get_info() is
returning some kind of EAGAIN, or some other Try again; we're busy
Test results for the patch.
mmaptest simply maps a range and write to it.
The length of the extent indicate whether it is initialized or not.
There is no space in the file system for another block.
So the uninitialized extent have to be converted to initialized extent.
[EMAIL PROTECTED]:/ext4#
On Fri, Feb 22, 2008 at 08:01:28PM +0530, Aneesh Kumar K.V wrote:
+
+ /* Now write all the buffer_heads in the page */
+ do {
+ set_buffer_uptodate(bh);
+ if (ext4_should_journal_data(inode)) {
+ err =
On Fri, Feb 22, 2008 at 09:02:56AM -0600, Eric Sandeen wrote:
Theodore Tso wrote:
This looks good, but I assume that the bug was caused by some race
condition where if you try to call dm_task_get_info() while some other
process is creating or removing a snapshot, dm_task_get_info() is
Theodore Tso wrote:
On Fri, Feb 22, 2008 at 09:02:56AM -0600, Eric Sandeen wrote:
Theodore Tso wrote:
This looks good, but I assume that the bug was caused by some race
condition where if you try to call dm_task_get_info() while some other
process is creating or removing a snapshot,
This looks good, but I assume that the bug was caused by some race
condition where if you try to call dm_task_get_info() while some other
process is creating or removing a snapshot, dm_task_get_info() is
returning some kind of EAGAIN, or some other Try again; we're busy
error, right?
If that is
On Fri, Feb 22, 2008 at 10:16:53AM -0600, Eric Sandeen wrote:
From a quick chat with agk, it sounds like outright failure is
appropriate. Sounds like most of the calls fail for reasons like ENOMEM
(but it might be nice if it returned that, eh?)
So the question then is why is it that Phillip
Theodore Tso wrote:
On Fri, Feb 22, 2008 at 10:16:53AM -0600, Eric Sandeen wrote:
From a quick chat with agk, it sounds like outright failure is
appropriate. Sounds like most of the calls fail for reasons like ENOMEM
(but it might be nice if it returned that, eh?)
So the question then is
On Friday 22 February 2008 5:08:47 am Jan Kara wrote:
Hello,
On Thu 21-02-08 13:58:55, Josef Bacik wrote:
This is related to that jbd patch I sent a few weeks ago. I originally
found that the problem where t_nr_buffers would be than
t_outstanding_credits wouldn't happen upstream, but
Theodore Tso wrote:
On Fri, Feb 22, 2008 at 01:07:13PM +0100, Bas van Schaik wrote:
Hi all,
Currently, I have a big problem: e2fsck refuses to fix my currupted
filesystem...
The things that I would suggest first of all is upgrading to the
latest version of e2fsprogs. If that doesn't
Bas van Schaik wrote:
In a few hours I will hit the road towards France for a holiday, from
which I will return on the 3rd of March. I would be _really_ grateful if
you could assist me solving this problem.
Providing the compressed e2image would let ted or others look into the
problem.
Bas van Schaik wrote:
In a few hours I will hit the road towards France for a holiday, from
which I will return on the 3rd of March. I would be _really_ grateful if
you could assist me solving this problem.
Providing the compressed e2image would let ted or others look into the
problem.
Bas van Schaik wrote:
Bas van Schaik wrote:
In a few hours I will hit the road towards France for a holiday, from
which I will return on the 3rd of March. I would be _really_ grateful if
you could assist me solving this problem.
Providing the compressed e2image would let ted or others look
Bas van Schaik wrote:
Bas van Schaik wrote:
In a few hours I will hit the road towards France for a holiday, from
which I will return on the 3rd of March. I would be _really_ grateful
if
you could assist me solving this problem.
Providing the compressed e2image would let ted or others look
On Fri, 2008-02-22 at 20:09 +0530, Aneesh Kumar K.V wrote:
We would like to get notified when we are doing a write on mmap section.
This is needed with respect to preallocated area. We split the preallocated
area into initialzed extent and uninitialzed extent in the call back. This
let us
You know what -- I went back and double-checked all the logs, and somehow
or other I must have recorded a timestamp wrong as 3:19:21 instead of
3:19:51.
The segfault did in fact happen at 3:19:51 a.m. which is exactly the same
time as my backup script moved on to the next filesystem.
So, it
On Fri, Feb 22, 2008 at 10:52:36AM -0600, Eric Sandeen wrote:
Theodore Tso wrote:
On Fri, Feb 22, 2008 at 10:16:53AM -0600, Eric Sandeen wrote:
From a quick chat with agk, it sounds like outright failure is
appropriate. Sounds like most of the calls fail for reasons like ENOMEM
(but it
On Fri, Feb 22, 2008 at 10:10:48AM -0800, Mingming Cao wrote:
On Fri, 2008-02-22 at 20:09 +0530, Aneesh Kumar K.V wrote:
.
+ ext4_journal_stop(handle);
+ goto out_unlock;
+ }
+ if (!ret ext4_should_order_data(inode)) {
+ ret =
On Fri, Feb 22, 2008 at 01:10:40PM -0500, Philip Spencer wrote:
You know what -- I went back and double-checked all the logs, and somehow
or other I must have recorded a timestamp wrong as 3:19:21 instead of
3:19:51.
The segfault did in fact happen at 3:19:51 a.m. which is exactly the same
On Fri, Feb 22, 2008 at 07:06:10PM +0100, Bas van Schaik wrote:
Bas van Schaik wrote:
Bas van Schaik wrote:
In a few hours I will hit the road towards France for a holiday, from
which I will return on the 3rd of March. I would be _really_ grateful
if
you could assist me solving this
On Fri, 2008-02-22 at 23:53 +0530, Aneesh Kumar K.V wrote:
On Fri, Feb 22, 2008 at 10:10:48AM -0800, Mingming Cao wrote:
On Fri, 2008-02-22 at 20:09 +0530, Aneesh Kumar K.V wrote:
.
+ ext4_journal_stop(handle);
+ goto out_unlock;
+ }
+ if (!ret
On Fri, Feb 22, 2008 at 07:06:10PM +0100, Bas van Schaik wrote:
Bas van Schaik wrote:
Bas van Schaik wrote:
In a few hours I will hit the road towards France for a holiday,
from
which I will return on the 3rd of March. I would be _really_
grateful
if
you could assist me solving
On Fri, Feb 22, 2008 at 08:31:13PM +0100, Bas van Schaik wrote:
Yeah, it could be quite big, given that you have a 3TB filesystem. That's
why I suggested the or given me login access to the system, although
understand there could be all sorts of privacy and security issues
involved with
In delayed allocation, blocks to be allocated need to be reserved
before user buffers being copied to memory, otherwise later at
page writeout time we could hit ENOSPC error.
In this patch, blocks(data and metadata) are reserved at da_write_begin()
time, the free blocks counter is updated by
Hi, ext4 patch queue has keeping a set of delayed allocation for a
while. The know todo is add reservation and ordered mode support.
FYI, The base delayed allocation patches are located at
VFS changes:
Since generally the current mainline VFS API changed to use write-begin()
and write_end(), updating ext4 delayed allocation to adopt this change.
Signed-off-by: Mingming Cao [EMAIL PROTECTED]
---
fs/ext4/inode.c | 36 ++--
1 file changed, 26 insertions(+), 10
With delayed allocation, get_block() is only doing block map at the
write_begin() time. If the blocks are prea-allocated, the result bh
is not mapped, but the blocks are actually being allocated.
delalloc should not treat it as other regular unallocated area, thus
mark it as need block allocation
On Feb 21, 2008 10:40 -0600, Eric Sandeen wrote:
Ok, but my concern is what happens to those long symlinks when they
really truly are in extents format. One option is to say hey it was
ext4DEV, deal with it and nuke the symlink, but if possible, converting
back to the proper format would be
On Fri, Feb 22, 2008 at 04:14:34PM -0700, Andreas Dilger wrote:
On Feb 21, 2008 10:40 -0600, Eric Sandeen wrote:
Ok, but my concern is what happens to those long symlinks when they
really truly are in extents format. One option is to say hey it was
ext4DEV, deal with it and nuke the
35 matches
Mail list logo
