Andrew Morton wrote:
Yes, there can be issues with needing to allocate journal space within the
context of a commit. But
no-no, this isn't required. we only need to mark pages/blocks within
transaction, otherwise race is possible when we allocate blocks in transaction,
then transacton starts
On Fri, 04 May 2007 10:18:12 +0400 Alex Tomas [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Yes, there can be issues with needing to allocate journal space within the
context of a commit. But
no-no, this isn't required. we only need to mark pages/blocks within
transaction, otherwise
On Thu, May 03, 2007 at 11:28:15PM -0700, Andrew Morton wrote:
The posix spec implies that negative `len' is permitted - presumably
allocate
ahead of `offset'. How peculiar.
I just checked the man page for posix_fallocate() and it says:
EINVAL offset or len was less
Andrew Morton wrote:
On Fri, 04 May 2007 10:18:12 +0400 Alex Tomas [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Yes, there can be issues with needing to allocate journal space within the
context of a commit. But
no-no, this isn't required. we only need to mark pages/blocks within
On Fri, 04 May 2007 10:57:12 +0400 Alex Tomas [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Fri, 04 May 2007 10:18:12 +0400 Alex Tomas [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Yes, there can be issues with needing to allocate journal space within the
context of a commit. But
On Thu, May 03, 2007 at 11:28:15PM -0700, Andrew Morton wrote:
On Fri, 4 May 2007 16:07:31 +1000 David Chinner [EMAIL PROTECTED] wrote:
On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:33:32 +0530 Amit K. Arora [EMAIL PROTECTED]
wrote:
This
Andrew Morton wrote:
I'm still not understanding. The terms you're using are a bit ambiguous.
What does find some dirty unallocated blocks mean? Find a page which is
dirty and which does not have a disk mapping?
Normally the above operation would be implemented via
On Fri, 04 May 2007 11:39:22 +0400 Alex Tomas [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
I'm still not understanding. The terms you're using are a bit ambiguous.
What does find some dirty unallocated blocks mean? Find a page which is
dirty and which does not have a disk mapping?
This is work in progress
Changes from from my previous patches are as follows:
a) COW unix io manager using libtdb
b) add ext4replay to undo the file system changes done during migration
Changes from from my previous patches are as follows:
a) Mark the file system unclean if we fail migrating
From: Aneesh Kumar K.V [EMAIL PROTECTED]
The code is derived out of the latest ext4 kernel source. I
have tried to keep the code as close as possible to the kernel
sources. This makes sure that any fixes for the tree building
code in kernel should be easily applied to ext4migrate. The
ext3_ext
From: Aneesh Kumar K.V [EMAIL PROTECTED]
Signed-off-by: Aneesh Kumar K.V [EMAIL PROTECTED]
---
lib/ext2fs/Makefile.in |6 +
lib/ext2fs/ext2_io.h |3 +
lib/ext2fs/unix_cow_io.c | 864 ++
3 files changed, 873 insertions(+), 0 deletions(-)
From: Aneesh Kumar K.V [EMAIL PROTECTED]
This tool can be used to replay the transactions stored in the database
during ext4migrate.
Signed-off-by: Aneesh Kumar K.V [EMAIL PROTECTED]
---
ext4migrate/Makefile.in |7 ++-
ext4migrate/replay.c| 45
From: Pekka Enberg [EMAIL PROTECTED]
As explained by Christoph Lameter, ext3_alloc_inode() touches the same
cache line as init_once() so we gain nothing from using slab
constructors. The SLUB allocator will be more effective without it
(free pointer can be placed inside the free'd object), so
On Fri, 4 May 2007, Pekka J Enberg wrote:
Index: 2.6/fs/ext3/super.c
===
--- 2.6.orig/fs/ext3/super.c 2007-05-04 12:57:09.0 +0300
+++ 2.6/fs/ext3/super.c 2007-05-04 13:01:27.0 +0300
@@ -444,17 +444,26 @@
Hi,
I ran this script tree times,
#! /bin/sh
for i in `find /sys/ -type f`
do
echo wyświetlam $i
sudo cat $i /dev/null
done
First run - scheduler bug
Second run - NOHZ bug
Third - VFS bug
H...
[93298.252601] BUG: at /mnt/md0/devel/linux-git/kernel/sched.c:3241
On Fri, 04 May 2007 18:20:51 +0200 Michal Piotrowski [EMAIL PROTECTED] wrote:
I ran this script tree times,
#! /bin/sh
for i in `find /sys/ -type f`
do
echo wyświetlam $i
sudo cat $i /dev/null
done
First run - scheduler bug
Second run - NOHZ bug
Third - VFS bug
On Fri, 4 May 2007 13:14:35 +0300 (EEST)
Pekka J Enberg [EMAIL PROTECTED] wrote:
As explained by Christoph Lameter, ext3_alloc_inode() touches the same
cache line as init_once() so we gain nothing from using slab
constructors. The SLUB allocator will be more effective without it
(free
17 matches
Mail list logo
