()]
*/
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue 05-02-08 13:59:05, Josef Bacik wrote:
On Tuesday 05 February 2008 12:27:31 pm Jan Kara wrote:
Hello,
Sorry for replying a bit late but I'm currently falling behind in
maling-list reading...
The way jbd tries to determine if there is enough space left on the
journal
Signed-off-by: Aneesh Kumar K.V [EMAIL PROTECTED]
Add Acked-by: Jan Kara [EMAIL PROTECTED] if you wish.
Honza
---
fs/ext4/migrate.c | 117 +---
1 files changed, 74
fine. You can add
Acked-by: Jan Kara [EMAIL PROTECTED]
if you wish.
Honza
diff -Nrup linux-2.6.24.org/fs/ext3/fsync.c linux-2.6.24/fs/ext3/fsync.c
--- linux-2.6.24.org/fs/ext3/fsync.c 2008-01-25 07:58:37.0 +0900
+++ linux
Hi,
this patch fixes lock inversion in ext4 direct IO path. The similar patch
has already been accepted for ext3. Mingming, will you put it into ext4
patch queue? Thanks.
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
On Tue 05-02-08 17:53:42, Aneesh Kumar K.V wrote:
On Mon, Feb 04, 2008 at 05:31:56PM +0100, Jan Kara wrote:
Hi,
On Mon 04-02-08 15:42:28, Aneesh Kumar K.V wrote:
This is with the new ext3 - ext4 migrate code added. The recently added
lockdep for jbd2 helped to find this out. We
On Tue 05-02-08 21:57:03, Aneesh Kumar K.V wrote:
On Tue, Feb 05, 2008 at 02:42:28PM +0100, Jan Kara wrote:
On Tue 05-02-08 17:53:42, Aneesh Kumar K.V wrote:
How about the patch below. I did the below testing
a) migrate a file
b) run fs_inode fsstres fsx_linux.
The intention
t_outstanding_credits
t_nr_buffers, then there's something fishy. Are you able to reproduce it
also with a current kernel?
Thanks for looking into the problem :)
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from
On Mon 04-02-08 22:42:08, Aneesh Kumar K.V wrote:
On Mon, Feb 04, 2008 at 05:31:56PM +0100, Jan Kara wrote:
Hi,
On Mon 04-02-08 15:42:28, Aneesh Kumar K.V wrote:
This is with the new ext3 - ext4 migrate code added. The recently added
lockdep for jbd2 helped to find this out. We
[c01e0de9] ext4_find_entry+0x350/0x5b7
[c01e200c] ext4_unlink+0x6e/0x1a4
[c017449e] vfs_unlink+0x49/0x89
[c0175f02] do_unlinkat+0x96/0x12c
[c0175fa8] sys_unlink+0x10/0x12
[c0104f8a] sysenter_past_esp+0x5f/0xa5
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
-
To unsubscribe from this list: send
Hi,
resending the patch just in case you've missed it.
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
Commit block was intended to have several copies of the header. But
due to a bug it never had them
On Fri 25-01-08 03:50:04, Andreas Dilger wrote:
On Jan 25, 2008 11:05 +0100, Jan Kara wrote:
For example ext2 on fsync() just sync's a single inode
(and has to use private_list to track metadata buffers associated with
the inode) while ext3 flushes the whole journal.
As for fsync(), we
Hi Andrew,
here's the patch I wrote you about.
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
Commit block was intended to have several copies of the header. But
due to a bug it never had them and actually, nobody checks
On Sat 26-01-08 22:02:07, Andrew Morton wrote:
On Wed, 23 Jan 2008 20:09:43 +0100 Jan Kara [EMAIL PROTECTED] wrote:
Commit block is expected to have several copies of the header. Fix the
bug Andrew has spotted ages ago.
ages indeed.
diff --git a/fs/jbd/commit.c b/fs/jbd
...
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
We cannot start transaction in ext3_direct_IO() and just let it last during the
whole write because dio_get_page() acquires mmap_sem which ranks above
transaction start (e.g. because we have dependency chain
mmap_sem-PageLock-journal_start
.
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
Commit block is expected to have several copies of the header. Fix the
bug Andrew has spotted ages ago.
Signed-off-by: Jan Kara [EMAIL PROTECTED]
diff --git a/fs/jbd/commit.c b/fs/jbd/commit.c
index 610264b..a69b240 100644
--- a/fs
On Wed 23-01-08 20:09:43, Jan Kara wrote:
Hi,
the patch below fixes preparation of commit block in
journal_write_commit_record(). Obviously the bug doesn't really matter
since nobody reported it so far but let's cleanup the code... Andrew, could
you please queue it up? Thanks
bitmap
data. But I don't think this really is a problem - fsck has to be run
anyway and it rebuilds the bitmaps from scratch.
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe
for explanation. So for JBD2 we don't need the patch
anymore. But for JBD it's still needed.
Honza
On Wed, 2008-01-23 at 20:10 +0100, Jan Kara wrote:
On Wed 23-01-08 20:09:43, Jan Kara wrote:
Hi,
the patch below fixes
On Mon 14-01-08 10:57:18, Theodore Tso wrote:
On Wed, Jan 09, 2008 at 08:54:35PM +0100, Jan Kara wrote:
Reading of bitmaps from image file could never work with more than one
group in a filesystem... Fix the loops so that we read appropriate number
of blocks.
OK, so I'm probably being
On Wed 09-01-08 23:54:28, Aneesh Kumar K.V wrote:
On Wed, Jan 09, 2008 at 01:10:41PM +0100, Jan Kara wrote:
With the multi block allocator when we don't have prealloc space we
discard
@@ -3790,7 +3782,9 @@ repeat:
/* if we still need more blocks and some PAs were used, try
Hi Ted,
I've sent you the attached fix some time ago but it didn't seem to get
merged yet...
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
Subject: Fix reading of bitmaps from filesystem image
Reading of bitmaps from
if someone decides to use it...
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
From: Andreas Dilger [EMAIL PROTECTED]
Make sure lost+found has always at least 2 disk blocks. This will provide at
least elementary test that we have
chunks
and better latency is thus ensured.
I'll try some tests to verify whether my theory is correct :).
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body
couldn't reproduce the bad behavior... But anyway, if my theory
is correct, attached patch should help - can you try it please? It's a
debugging quality only but shouldn't do anything bad to your data :)
Honza
--
Jan Kara
.
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
Subject: Support for 64KB blocksize in ext2-4 directories.
When block size is 64KB, we have to take care that rec_len does not overflow.
Kernel stores 0x in case 0x1 should be stored - perform
it...
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
From: Andreas Dilger [EMAIL PROTECTED]
Make sure lost+found has always at least 2 disk blocks. This will provide at
least elementary test that we have not screwed-up support for 64KB blocks since
the second directory
Hi,
reading of bitmaps from a filesystem image seems to be busted. The patch
below fixes it for me.
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
Subject: Fix reading of bitmaps from filesystem image
Reading
Hi,
the patch below should fix an assertion failure in JBD checkpointing
code. The patch survived some fsstress and similar runs on my test machine
so it shouldn't be obviously wrong ;).
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE
;
+ }
So this above is just a while loop coded with goto... While loop
would be IMO better.
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4
On Wed 21-11-07 00:40:17, Coly Li wrote:
Jan Kara wrote:
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 17b5df1..f838a72 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -10,6 +10,8 @@
* Stephen Tweedie ([EMAIL PROTECTED]), 1993
* Big-endian to little-endian
2b 16 19 c0 85 c0 75 ec 8b 46 04 85 c0 7f 30 c7 44 24
: EIP: [journal_put_journal_head+64/209] journal_put_journal_head+0x40/0xd1
SS:ESP 0068:c2bf7e38
: note: kswapd0[243] exited with preempt_count 2
Honza
--
Jan Kara
On Sat 10-11-07 19:37:03, Theodore Tso wrote:
On Wed, Nov 07, 2007 at 05:09:39PM +0100, Jan Kara wrote:
Subject: Support for 64KB blocksize in ext2-4 directories.
When block size is 64KB, we have to take care that rec_len does not
overflow.
Kernel stores 0x in case 0x1
On Mon 12-11-07 09:58:23, Theodore Tso wrote:
On Mon, Nov 12, 2007 at 10:52:45AM +0100, Jan Kara wrote:
Did you test this patch before submitting it?
Argh, stupid me. I've just tested that I didn't break anything for normal
block size and thought that I cannot make mistake
On Wed 07-11-07 19:20:38, Theodore Tso wrote:
On Wed, Nov 07, 2007 at 03:36:05PM +0100, Jan Kara wrote:
What if more than one application wants to use this facility?
That should be fine - let's see: Each application keeps somewhere a time
when
it started a scan of a subtree
for rsync yet, so I can underestimate...
On Thu, Nov 08, 2007 at 11:56:42AM +0100, Jan Kara wrote:
Note by the way that since you need to own the file/directory to set
flags, this means that only programs that are running as root or
running as the uid who owns the entire subtree
On Tue 06-11-07 10:04:47, H. Peter Anvin wrote:
Arjan van de Ven wrote:
On Tue, 6 Nov 2007 18:19:45 +0100
Jan Kara [EMAIL PROTECTED] wrote:
Implement recursive mtime (rtime) feature for ext3. The feature works
as follows: In each directory we keep a flag EXT3_RTIME_FL
(modifiable by a user
On Tue 06-11-07 18:01:00, Al Viro wrote:
On Tue, Nov 06, 2007 at 06:19:45PM +0100, Jan Kara wrote:
Implement recursive mtime (rtime) feature for ext3. The feature works as
follows: In each directory we keep a flag EXT3_RTIME_FL (modifiable by a
user)
whether rtime should be updated
Hello,
sorry for replying to myself but I've just found out that the patch I've
sent was and old version of the patch which had some problems. Attached is
a new version.
On Tue 06-11-07 12:31:42, Jan Kara wrote:
it seems attached patch still did not get your attention. It makes
e2fsprogs
Wrote wrong mailing list address so I'm resending it to a correct one.
- Forwarded message from Jan Kara [EMAIL PROTECTED] -
From: Jan Kara [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [PATCH] e2fsprogs: Handle rec_len correctly for 64KB blocksize
Hello Ted
), please
contact me. Attached are sources of simple tools set_recmod, get_recmod
for testing the feature and also a patch implementing basic support of
the feature in e2fsprogs. Comments welcome.
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE
Hello,
the following patch makes more lightweight handling of
EXT3_I(inode)-i_flags possible.
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
Implement atomic updates of EXT3_I(inode)-i_flags. So far the i_flags access
Make space reserved for fragments as unused as they were never implemented.
Remove also related initializations. We later use the space for recursive
mtime.
Signed-off-by: Jan Kara [EMAIL PROTECTED]
diff -rupX /home/jack/.kerndiffexclude
linux-2.6.23-1-i_flags_atomicity/fs/ext3/ialloc.c
linux
properly updated and thus any application has an
effective way of finding new hardlinked files).
Signed-off-by: Jan Kara [EMAIL PROTECTED]
diff -rupX /home/jack/.kerndiffexclude
linux-2.6.23-2-ext3_make_frags_unused/fs/ext3/ialloc.c
linux-2.6.23-3-ext3_recursive_mtime/fs/ext3/ialloc.c
--- linux
(or nasty
things would happen if somebody actually try 64KB blocksize in ext3).
Thanks
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
With 64KB blocksize, a directory entry can
in quota_write but that's
also non-trivial.
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
if there are
any problems with the patch.
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
---
Subject: Support for 64KB blocksize in ext2-4 directories.
When block size is 64KB, we have to take care that rec_len does not overflow
Kumar K.V [EMAIL PROTECTED]
Cc: linux-ext4@vger.kernel.org
Cc: Eric Sandeen [EMAIL PROTECTED]
Cc: Jan Kara [EMAIL PROTECTED]
Cc: Dave Jones [EMAIL PROTECTED]
Cc: Chuck Ebbert [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
fs/ext3/super.c | 16
1
more.
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
-rc8-mm2), the patch fixing rec_len overflow clashes only for ext2...
I'll send you an updated patch for ext2 in a moment.
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
-
To unsubscribe from this list: send the line
On Thu 04-10-07 13:12:07, Andrew Morton wrote:
On Mon, 01 Oct 2007 17:35:46 -0700
Mingming Cao [EMAIL PROTECTED] wrote:
ext2: Avoid rec_len overflow with 64KB block size
From: Jan Kara [EMAIL PROTECTED]
With 64KB blocksize, a directory entry can have size 64KB which does not fit
Hello,
I am looking at ext4_max_size and was confused how the
number upper_limit = 0x1ff7fffd000LL is arrived.
The comment says the value is arrived looking at 4K.
So i tried the below program.
main()
{
unsigned long long upper_limit, meta_blocks;
int bits = 12;
On Thu 04-10-07 13:12:07, Andrew Morton wrote:
On Mon, 01 Oct 2007 17:35:46 -0700
Mingming Cao [EMAIL PROTECTED] wrote:
ext2: Avoid rec_len overflow with 64KB block size
From: Jan Kara [EMAIL PROTECTED]
With 64KB blocksize, a directory entry can have size 64KB which does not fit
won't be marked as with errors later (and user could happily
mount
it without any warning).
Signed-off-by: Jan Kara [EMAIL PROTECTED]
diff -rupX /home/jack/.kerndiffexclude
linux-2.6.23-rc6-1-jbd_abort_fix/fs/jbd2/commit.c
linux-2.6.23-rc6-2-jbd2_abort_fix/fs/jbd2/commit.c
--- linux-2.6.23-rc6-1
On Tue, 25 Sep 2007 07:49:38 -0500
Jose R. Santos [EMAIL PROTECTED] wrote:
On Tue, 25 Sep 2007 13:50:46 +0200
Jan Kara [EMAIL PROTECTED] wrote:
Jan Kara wrote:
-#define create_jbd_proc_entry() do {} while (0)
-#define remove_jbd_proc_entry() do {} while (0)
+static
Hi,
attached patch implements support for 64KB blocksize in directories in
e2fsprogs. This patch complements the kernel patches for ext2-4 I've sent
yesterday. Ted, does the patch look fine?
Honza
--
Jan Kara [EMAIL PROTECTED
Hi,
In the following series I'm sending patches to ext2, ext3 and ext4
solving possible overflow of rec_len when using 64KB blocksize. Minming,
would you add these to the patch queue? Thanks.
Honza
--
Jan Kara [EMAIL PROTECTED
With 64KB blocksize, a directory entry can have size 64KB which does not fit
into 16 bits we have for entry lenght. So we store 0x instead and convert
value when read from / written to disk.
Signed-off-by: Jan Kara [EMAIL PROTECTED]
diff -rupX /home/jack/.kerndiffexclude linux-2.6.23-rc6/fs
-off-by: Jan Kara [EMAIL PROTECTED]
diff -rupX /home/jack/.kerndiffexclude linux-2.6.23-rc6/fs/ext4/dir.c
linux-2.6.23-rc6-1-ext4_64k_blocksize/fs/ext4/dir.c
--- linux-2.6.23-rc6/fs/ext4/dir.c 2007-09-18 19:22:28.0 +0200
+++ linux-2.6.23-rc6-1-ext4_64k_blocksize/fs/ext4/dir.c 2007-09
are safe). Any feeling
what is less hacky?
Honza
--
Jan Kara [EMAIL PROTECTED]
SUSE Labs, CR
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info
? That would be IMHO more transparent than current approach (at
least it took me some time to understand what's going on with the
current patch when I was looking at the code)...
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
On Thu 20-09-07 11:14:40, Theodore Tso wrote:
On Thu, Sep 20, 2007 at 04:58:39PM +0200, Jan Kara wrote:
Hmm, strange - I've just looked at my computer and dir_index is set
just for 5 directories in my tree.
I looked at a tree that had object files, which is probably why I had
8
.
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
With 64KB blocksize, a directory entry can have size 64KB which does not fit
into 16 bits we have for entry lenght. So we store 0x instead and convert
value when read from
some
operations like deleting the whole directory, etc. So what is the reason
for starting building the tree so early? Just the simplicity of building it
when the directory is just one block large?
Honza
--
Jan Kara [EMAIL
-By : ?
Handled-By : ?
Status : unknown
I thought Shaggy asked Oliver about some details (and he did not
answer so far) so I'd assume Shaggy is handling this.
Honza
--
Jan Kara [EMAIL PROTECTED
returns a number of extents stored. Note that the result of the
function is unreliable as the space can be already allocated by the time system
call returns.
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message
On Thu 16-08-07 12:37:45, Josef Bacik wrote:
On Thu, Aug 16, 2007 at 06:08:35PM +0200, Jan Kara wrote:
It is possible to panic the box by a race condition that exists in the
journalling code where we do not take the j_revoke_lock when
traversing the
journal's revoked record
Hello,
It is possible to panic the box by a race condition that exists in the
journalling code where we do not take the j_revoke_lock when traversing
the
journal's revoked record list. This patch has been tested and we haven't
seen
the issue yet, its a rather
...
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue 29-05-07 14:10:52, Mingming Cao wrote:
On Mon, 2007-05-28 at 18:04 +0200, Jan Kara wrote:
On Wed 23-05-07 08:37:43, Theodore Tso wrote:
On Tue, May 22, 2007 at 06:11:27PM +0200, Jan Kara wrote:
while fixing some problems with preallocation in UDF, I had a look how
ext2
On Wed 23-05-07 08:37:43, Theodore Tso wrote:
On Tue, May 22, 2007 at 06:11:27PM +0200, Jan Kara wrote:
while fixing some problems with preallocation in UDF, I had a look how
ext2 solves similar problems. I found out that ext2_discard_prealloc() is
called on every iput() from
On Mon, 2007-05-21 at 12:38 +0200, Jan Kara wrote:
Yes. On the other hand I believe that some people would like to use
defragmentation but stay with ext3. For them conversion to extents is
no-go.
[...]
I've written a patch that defragments non-extent files but after
discussion
ext2_discard_prealloc() from ext2_release_file()
is suboptimal, isn't it?
Thanks for answer
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4
On Thu, 2007-05-17 at 18:11 +0200, Jan Kara wrote:
But me (and several other people
independently as I've learnt recently) have written some tools which
should result in something useful. If you're interested, you can join
[EMAIL PROTECTED] - it's led by one guy who is doing
defrag
to my defrag tool in order to defragment indirect block files.
How do you think of it?
Yes that could be useful but I don't think it's a complete solution
for people that don't want to migrate.
Honza
--
Jan Kara [EMAIL PROTECTED
On Mon 16-04-07 12:14:21, Andreas Dilger wrote:
On Apr 16, 2007 19:05 +0200, Jan Kara wrote:
attached is a patch that stores inode flags such as S_IMMUTABLE,
S_APPEND, etc. from i_flags to EXT3_I(inode)-i_flags when inode is
written to disk. The same thing is done on GETFLAGS ioctl
Kara [EMAIL PROTECTED]
SuSE CR Labs
Propagate flags such as S_APPEND, S_IMMUTABLE, etc. from i_flags into
ext3-specific i_flags. Hence, when someone sets these flags via a different
interface than ioctl, they are stored correctly.
Signed-off-by: Jan Kara [EMAIL PROTECTED]
diff -rupX /home/jack
Hi,
attached is a port of the previous patch for ext3 to ext4.
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
Propagate flags such as S_APPEND, S_IMMUTABLE, etc. from i_flags into
ext4-specific i_flags. Hence, when
himself) and these changes were not correctly
propagated into the filesystem (especially, lsattr did not show them and
users were wondering...).
If people agree that this patch is fine, I can also rediff it for
ext4.
Honza
--
Jan Kara
for reconstruction
in the header...
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
On Wed 28-03-07 19:00:54, Ric Wheeler wrote:
Jan Kara wrote:
[EMAIL PROTECTED] wrote:
Hi all,
We are building a new system which is going to use ext3 FS. We would
like to know more about the behavior of ext3 in the case of failure.
But before I procede, I would like to share more
Hello,
I'm trying to look at the ext2/ext3 source for learning Linux FS
development. I'm avoiding ext4 for now because it's under active
development and it's too much to chew before I understand the previous
versions. But am I going to get an outdated view of the right way to
program
.
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
is written after fsync(); poweroff; that is a bug worth reporting..
Honza
-Original Message-
From: John Anthony Kazos Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 9:17 AM
To: Jan Kara
Cc: wheeler, richard
On Tue 06-03-07 12:23:22, Eric Sandeen wrote:
Jan Kara wrote:
On Tue 06-03-07 06:36:09, Ulrich Drepper wrote:
Christoph Hellwig wrote:
fallocate with the whence argument and flags is already quite complicated,
I'd rather have another call for placement decisions, that would
be called
because it needs a few blocks from a ton of
distinct files (shared libs, config files, etc). As these files are mostly
read only, it's advantageous to interleave them on disk or at least keep
them close.
Honza
--
Jan Kara
guide
preallocation for things like defragmentation (e.g. preallocate space
for the file being defragmented and move the file to it).
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line
place where S_IMMUTABLE flag is set to an inode so this is not a
big issue but still...
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message
at least to the
original state. But that's probably not important.
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED
On Thu 08-02-07 02:32:13, Andrew Morton wrote:
On Thu, 8 Feb 2007 11:21:02 +0100 Jan Kara [EMAIL PROTECTED] wrote:
On Thu 08-02-07 01:45:29, Andrew Morton wrote:
snip
I though Andreas meant any write changes - i.e. you check that noone
has open file descriptor for writing
the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL
it).
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 03, 2006 at 03:30:30PM +0100, Jan Kara wrote:
BTW, does use of sysfs mean ASCII encoding of all the data
passing between kernel and userspace?
Not necessarify but mostly yes. At least I intend to have all the
files I have proposed in ASCII.
Ok - that's how you're
...
Bye
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo
.
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
part of the problem and let
filesystem sort out metadata?
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More
). But still if you would like to
relocate the file by parts this is not quite what you want (you won't be
able to relocate indirect blocks in the boundary of intervals) :(.
Honza
--
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
To unsubscribe from
On Wed, Oct 25, 2006 at 04:54:50PM +0200, Jan Kara wrote:
Yes, this sounds feasible. We could split the defrag ioctl into two
pieces (addition of given extent to a file and swapping of extents), which
can have generic interface...
An ioctl is UGLY.
Agreed.
This was discussed years
On Wed, Oct 25, 2006 at 07:58:51PM +0200, Jan Kara wrote:
I've briefly looked at this and this kind of interface has some
appeal. On the other hand it's not obvious to me, how to implement in
this interface *atomic* operation copy data from file F to given set of
blocks and rewrite
On Oct 23, 2006 18:03 +0200, Jan Kara wrote:
Andreas Dilger wrote:
I would in fact go so far as to allow only a single extent to be specified
per call. This is to avoid the passing of any pointers as part of the
interface (hello ioctl police :-), and also makes the kernel code
1 - 100 of 106 matches
Mail list logo
