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 t
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 woul
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 then,
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
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 d
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:
http://repo.or.cz/w/ext4-patch-queue.git?a=blob;f=delalloc-vfs.patch;h=713004ca3f01ae9e7ace289c5
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
> > involv
> 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
>>
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 (!
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
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 sa
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 = walk_pa
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
> >
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, 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 h
> 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 wou
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
> 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
> pr
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.
Tha
> 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 e2fsp
Aneesh Kumar K.V wrote:
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)) {
+
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 upstr
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 t
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
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 i
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
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
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)) {
> > > +
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#
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 39
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 handle ENOSPC better. Otherwise we get ENOSPC in the writepage and
t
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
On Thu, Feb 21, 2008 at 01:07:17PM -0800, Mingming Cao wrote:
> Hi Aneesh,
>
> It's a good start, a few comments below..
>
.
> > + page = __grab_cache_page(mapping, index);
> > + if (!page)
> > + return -ENOMEM;
> > +
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
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
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 fix it, I'm going to
nee
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 f
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 mess
39 matches
Mail list logo