AIX stores all of this information in the LVM, not in the filesystem.
The filesystem itself has nothing to do with importing and exporting
volume groups. Having the information stored as part of LVM's metadata
allows the utilities to only deal with LVM instead of every individual
file system.
Alexander Viro wrote:
On Fri, 23 Mar 2001, Dave Kleikamp wrote:
Are you okay with JFS using a few ioctl's in the utilities and
continuing the discussion of whether more general-purpose metadata
access should occur in procfs or under your proposal?
OK, one immediate problem
Al,
I didn't know that creating file system ioctl's was such a hot topic.
Since the functions I want to implement are for a very specific purpose
(I don't expect anything except the JFS utilities to invoke them), I
would expect an ioctl to be an appropriate vehicle.
If not ioctl's, why not
My turn to chime in.
JFS was designed around a 4K meta-data page size. It would require some
major re-design to use larger block sizes. On the other hand, JFS could
take advantage of 64-bit block addresses immediately. JFS internally
store the block address in 40 bits. (Sorry, file size
This is a WAG, but:
1. Did you build ext3 as a module?
2. If so, are you running on a kernel that was built before applying the
ext3 patch and configuring?
If the answers are yes, the inode cache may be too small to contain the
ext3 in-memory inode, and the ext3 code is overwriting the inode
On Fri, 2005-02-25 at 20:34 -0800, Frederik Eaton wrote:
Does JFS have problems with files with special characters in them?
Sometimes. jfs attempts to store pathnames in 16-bit unicode, and uses
the mount option iocharset to determine what to convert to/from.
In the 2.4 kernel, the default
On Sun, 2005-02-27 at 15:00 -0800, Frederik Eaton wrote:
Thanks, you were right that I recently upgraded to 2.6 (actually I
transferred the hard drive between machines), and with a mount /home -o
remount,iocharset=utf8 at least I can access the files now. But the
names aren't what they should
On Wed, 2005-03-16 at 20:52 -0800, Max wrote:
Bryan,
I'm not experienced in filesystems. But I've derived the testcase
program from some buggy application that occasionally created huge
files on my fs. That was not so easy to reproduce since not every
sequence of seeks/reads/writes results
On Thu, 2005-03-17 at 14:51 -0600, Dave Kleikamp wrote:
On Thu, 2005-03-17 at 12:06 -0800, Bryan Henderson wrote:
I found
that for larger values, your test program is returning -1, but unsigned
it appears as 18446744073709551615.
You mean you ran it? Then what about the more
With this change, the file size on jfs becomes 2^48 + 4 as expected.
--- jfs_bug.c.orig 2005-03-17 14:18:48.229634648 -0600
+++ jfs_bug.c 2005-03-17 15:32:45.952750104 -0600
@@ -13,12 +13,14 @@ int data = 0;
struct flock fl;
void read1() {
-size_t rc = fread(data,sizeof(data),1,f);
On Thu, 2005-03-17 at 13:48 -0800, Max wrote:
Dave,
Shouldn't fread(data,sizeof(data),1,f) and read(fn, data,
sizeof(data)) produce identical results?
Is it a bug or what?
fseek(f, offset, SEEK_SET);
fread(data, sizeof(data, 1, f);
should produce identical results to
lseek(fn, offset,
Here's the jfs implementation. The first patch fixes the transaction
layering in the xattr code to allow xattrs to be added to an inode as a
part of an existing transaction, and correctly calls jfs_init_acl()
within the same transaction that creates a file/directory/device.
The second patch
__jfs_setxattr should allow extended attributes to be set within an
existing transaction
diff -urp linux-2.6.13-rc3/fs/jfs/acl.c linux-1/fs/jfs/acl.c
--- linux-2.6.13-rc3/fs/jfs/acl.c 2005-07-13 10:03:40.0 -0500
+++ linux-1/fs/jfs/acl.c2005-07-14 09:19:50.0 -0500
@@
Implement jfs_init_security()
diff -Nurp linux-1/fs/jfs/jfs_xattr.h linux/fs/jfs/jfs_xattr.h
--- linux-1/fs/jfs/jfs_xattr.h 2005-07-13 16:59:04.0 -0500
+++ linux/fs/jfs/jfs_xattr.h2005-07-14 10:27:23.0 -0500
@@ -61,4 +61,14 @@ extern ssize_t jfs_getxattr(struct dentr
extern
On Fri, 2005-08-19 at 01:10 +0530, Dave Schwartz wrote:
Hi list,
Not too sure if this is the right forum to ask this question but since
my requirement is around linux filesystems, I shall take this liberty
to post my question.
My requirement is to develop a kernel/user space module to
On Fri, 2005-09-02 at 11:55 +0200, David Sanchez wrote:
Hi,
Please, could somebody explain me what the mark_inode_dirty* functions
do and what is the difference between mark_inode_dirty and
mark_inode_dirty_sync ?
They put the inode on the superblock's dirty list and make the inode as
dirty
On Fri, 2006-11-17 at 10:06 -0500, Jeff Layton wrote:
On Fri, 2006-11-17 at 09:01 -0600, Dave Kleikamp wrote:
Wouldn't you only be able to only crack a few of the low-order bits due
to a cluster of inodes being sequential? I don't think you'd be able
crack enough of it to be useful. You
On Thu, 2007-01-18 at 10:18 +1100, Jens Axboe wrote:
Can you try io_schedule() and verify that things just work?
I actually did do that in the first place, but wondered if it was the
right thing to introduce the accounting changes that came with that.
I'll change it back to io_schedule() and
On Thu, 2007-01-18 at 10:46 +1100, Jens Axboe wrote:
On Wed, Jan 17 2007, Dave Kleikamp wrote:
On Thu, 2007-01-18 at 10:18 +1100, Jens Axboe wrote:
Can you try io_schedule() and verify that things just work?
I actually did do that in the first place, but wondered if it was the
right
On Thu, 2007-01-18 at 01:30 -0500, Josef Sipek wrote:
On Wed, Jan 17, 2007 at 04:55:49PM -0600, Dave Kleikamp wrote:
/*
* jfs_lock.h
@@ -42,6 +43,7 @@ do {
\
if (cond
On Fri, 2007-01-26 at 09:51 +0300, Pavel Fedin wrote:
Hello!
This small patch fixes a problem with smbfs in 2.6.19.2 kernel.
Should also apply to other kernels.
NACK
The problem is that smbfs doesn't understand user and noexec
options. This makes it impossible to include into
On Thu, 2007-02-15 at 07:31 +1100, David Chinner wrote:
On Wed, Feb 14, 2007 at 11:54:54AM -0800, Valerie Henson wrote:
Just some quick notes on possible ways to fix the ext2 fsync bug that
eXplode found. Whether or not anyone will bother to implement it is
another matter.
Background:
On Thu, 2007-02-15 at 09:20 -0500, Theodore Tso wrote:
Another very heavyweight approach would be to simply force a full sync
of the filesystem whenever fysnc() is called. Not pretty, and without
the proper write ordering, the race is still potentially there.
I don't think this race is an
On Thu, 2007-02-15 at 10:59 -0500, sfaibish wrote:
On Thu, 15 Feb 2007 10:09:22 -0500, Dave Kleikamp
[EMAIL PROTECTED] wrote:
On Thu, 2007-02-15 at 09:20 -0500, Theodore Tso wrote:
Another very heavyweight approach would be to simply force a full sync
of the filesystem whenever fysnc
On Thu, 2007-02-15 at 11:11 -0800, Junfeng Yang wrote:
Hmm. If jfs has the problem, it is a bug. jfs is designed to
handle
this correctly. I'm pretty sure I've fixed at least one bug
that
eXplode has uncovered in the past. I'm not sure what was
On Mon, 2007-02-19 at 21:09 +0100, Jan Engelhardt wrote:
Hello,
simple_lookup() in fs/libfs.c does some extra steps, namely
dentry-d_op = simple_dentry_operations;
d_add(dentry, NULL);
as far as I understand, this creates a negative dentry which will be
deleted sometime
On Mon, 2007-02-19 at 21:31 +, Jörn Engel wrote:
Looks like I really write the first log-structured filesystem for Linux.
At least I can into a fairly arcane race that seems to be generic to all
of them.
Writing when space is tight may involve calling the garbage collector.
The garbage
On Mon, 2007-02-19 at 23:23 +, Jörn Engel wrote:
On Mon, 19 February 2007 17:05:55 -0600, Dave Kleikamp wrote:
It'd be nice if you could drop s_w_mutex when the garbage collector
calls i_get().
Not possible. Garbage collection only happens when space is getting
tight
On Tue, 2007-02-20 at 02:31 -0500, Hank Leininger wrote:
Is there anything provided by the kernel that would let you see the
current offset of an existing filehandle?
Sometimes when processing a very large file (grepping a log, bzip2'ing
or gpg'ing a file, or whatever), I'd really like to
On Tue, 2007-02-20 at 21:39 +, Valerie Henson wrote:
On Tue, Feb 20, 2007 at 01:30:25PM -0800, Junfeng Yang wrote:
On 2/20/07, Valerie Henson [EMAIL PROTECTED] wrote:
Google. (GoogleFS runs on top of ext2.)
It's surprising to know that... I guess they reply on GoogleFS's own
On Fri, 2007-02-23 at 10:02 -0600, Steve French (smfltc) wrote:
A field in i_size_write (i_size_seqcount) must be protected against
simultaneous update otherwise we risk looping in i_size_read.
The suggestion in fs.h is to use i_mutex which seems too dangerous due
to the possibility of
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
Amit K. Arora [EMAIL PROTECTED] wrote:
+asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
+{
+ struct file *file;
+ struct inode *inode;
+ long ret = -EINVAL;
+ file =
On Thu, 2007-03-01 at 14:59 -0800, Andrew Morton wrote:
On Thu, 01 Mar 2007 22:44:16 +
Dave Kleikamp [EMAIL PROTECTED] wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
Amit K. Arora [EMAIL PROTECTED] wrote:
+asmlinkage long
On Fri, 2007-03-02 at 18:45 +0800, Andreas Dilger wrote:
On Mar 01, 2007 13:15 -0600, Eric Sandeen wrote:
One thing I'd like to see is a cmd argument as well, to allow for
example allocation vs. reservation (i.e. allocating blocks vs. simply
reserving a number), as well as the inverse of
Amit wrote:
asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len);
On Thu, 2007-03-01 at 22:16 -0800, Andrew Morton wrote:
On Thu, 01 Mar 2007 22:03:55 -0800 Badari Pulavarty [EMAIL PROTECTED] wrote:
Just curious .. What does posix_fallocate() return ?
bookmark this:
On Fri, 2007-03-09 at 14:54 +0100, Miklos Szeredi wrote:
Comments are welcome.
This patch adds support for finding out the current file position,
open flags and possibly other info in the future.
These new entries are added:
/proc/PID/fdinfo/FD
/proc/PID/task/TID/fdinfo/FD
On Fri, 2007-03-09 at 10:23 -0500, Benjamin LaHaise wrote:
On Fri, Mar 09, 2007 at 09:15:06AM -0600, Dave Kleikamp wrote:
I think this information would be a little easier to access if there
would be a single file per pid or thread containing something like:
handle flags pos
On Thu, 2007-03-08 at 23:39 +0100, Ihar `Philips` Filipau wrote:
The problem have beaten me before. And now I have it again.
Imaging external hard drive with proper file system (proper ==
supports posix permissions) where files were created by user A and
then it (ext. hard drive) was
On Fri, 2007-03-09 at 22:03 +0100, Miklos Szeredi wrote:
I think this information would be a little easier to access if there
would be a single file per pid or thread containing something like:
handle flags pos path
0 012 1234/dev/pts/1
1 014 5678
On Wed, 2007-03-28 at 02:45 -0400, Xin Zhao wrote:
Hi,
If a Linux process opens and reads a file A, then it closes the file.
Will Linux keep the file A's data in cache for a while in case another
process opens and reads the same in a short time? I think that is what
I heard before.
Yes.
.
The jfsIO thread should set its state before giving up the spinlock, so
the waking thread will really wake it.
Signed-off-by: Dave Kleikamp [EMAIL PROTECTED]
diff --git a/fs/jfs/jfs_logmgr.c b/fs/jfs/jfs_logmgr.c
index ff7f1be..16c6268 100644
--- a/fs/jfs/jfs_logmgr.c
+++ b/fs/jfs/jfs_logmgr.c
On Tue, 2007-05-08 at 16:22 +0530, Amit K. Arora wrote:
On Mon, May 07, 2007 at 10:24:37AM -0500, Dave Kleikamp wrote:
On Mon, 2007-05-07 at 17:37 +0530, Amit K. Arora wrote:
On Thu, May 03, 2007 at 09:31:33PM -0700, Andrew Morton wrote:
So we don't implement fallocate on bitmap-based
On Wed, 2007-05-16 at 13:16 +1000, David Chinner wrote:
On Wed, May 16, 2007 at 01:33:59AM +0530, Amit K. Arora wrote:
Following changes were made to the previous version:
1) Added description before sys_fallocate() definition.
2) Return EINVAL for len=0 (With new draft that Ulrich
On Thu, 2007-05-17 at 09:40 +1000, David Chinner wrote:
On Wed, May 16, 2007 at 07:21:16AM -0500, Dave Kleikamp wrote:
On Wed, 2007-05-16 at 13:16 +1000, David Chinner wrote:
Please don't make this always happen. c/mtime updates should be dependent
on the mode being used and whether
On Thu, 2007-05-24 at 02:06 +0800, coly wrote:
The patch is generated based on 2.6.20-ext4-2 branch. you can find the
benchmark from other email.
DO NOT waste time on reading the patch :-) I post this patch here is to
show that I really spent time on it and the patch can work (even not
On Thu, 2007-05-31 at 16:25 +0200, Jörn Engel wrote:
--- linux-2.6.21logfs/fs/jfs/jfs_txnmgr.c~I_LOCK2007-05-07
10:28:55.0 +0200
+++ linux-2.6.21logfs/fs/jfs/jfs_txnmgr.c 2007-05-29
13:10:32.0 +0200
@@ -1286,7 +1286,14 @@ int txCommit(tid_t tid, /*
On Mon, 2007-06-25 at 11:27 -0700, Dave Hansen wrote:
On Sat, 2007-06-23 at 08:45 +0100, Christoph Hellwig wrote:
You probably want to add a big comment explaining why it's fine here.
I've got this in the next set:
-
- if(IS_RDONLY(nd.dentry-d_inode))
+ /*
+* This
On Thu, 2007-06-28 at 11:33 -0700, Andrew Morton wrote:
On Thu, 28 Jun 2007 23:27:57 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
Please drop the non-ext4 patches from the ext4 tree and send incremental
patches against the (non-ext4) fallocate patches in -mm.
Please let us know what
On Mon, 2007-07-09 at 22:00 +0200, Jörn Engel wrote:
On Mon, 9 July 2007 22:01:48 +0400, Alexey Dobriyan wrote:
Yes. Note that ext2_clear_inode() is referenced from ext2_sops, so even
empty, it leaves traces in resulting kernel.
Is that your opinion or have you actually measured a
On Wed, 2007-07-11 at 15:05 +1000, Neil Brown wrote:
It just occurred to me:
If i_version is 64bit, then knfsd would need to be careful when
reading it on a 32bit host. What are the locking rules?
How does knfsd use i_version? I would think that if all it was doing
was to compare
Sorry for the late response, but I'm interested in attending. I didn't
think I would be able to justify the trip for the one-day meeting, but I
begged an invitation to the VM summit from Martin. I still need to get
travel approval, but I'm optimistic that I can justify the trip now.
Thanks,
On Tue, 2007-07-31 at 13:11 -0400, Josef Sipek wrote:
On Tue, Jul 31, 2007 at 07:00:12PM +0200, Jan Blunck wrote:
On Tue, Jul 31, Josef Sipek wrote:
On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote:
Introduce white-out support to ext2.
I think storing whiteouts on the
On Wed, 2007-08-01 at 14:44 -0400, Josef Sipek wrote:
Alright not the greatest of examples, there is something to be said about
symmetry, so...let me try again :)
/a/
/b/bar(whiteout for bar)
/c/foo/qwerty
Now, let's mount a union of {a,b,c}, and we'll see:
$ find /u
On Mon, 2007-08-06 at 09:54 -0400, Jeff Layton wrote:
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
Acked-by: Dave Kleikamp [EMAIL PROTECTED]
---
fs/jfs/acl.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/jfs/acl.c b/fs/jfs/acl.c
index 4d84bdc..34ca314 100644
.
Here's my ack for the jfs piece.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
Acked-by: Dave Kleikamp [EMAIL PROTECTED]
--
David Kleikamp
IBM Linux Technology Center
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More
On Wed, 2007-08-29 at 23:17 -0500, Shaun Zinck wrote:
This replaces some macros and code, which do the same thing as DIV_ROUND_UP
defined in kernel.h, to use the DIV_ROUND_UP macro.
Signed-off-by: Shaun Zinck [EMAIL PROTECTED]
Thanks. I've added this to the jfs git tree. It's queued for
On Sat, 2007-09-08 at 13:11 +0200, Michal Piotrowski wrote:
Hi all,
Here is a list of some known regressions in 2.6.23-rc5.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
FS
Subject : umount triggers a warning in jfs and takes
On Tue, 2007-09-18 at 16:24 +0200, Jan Kara wrote:
Subject : umount triggers a warning in jfs and takes almost a minute
References : http://lkml.org/lkml/2007/9/4/73
Last known good : ?
Submitter : Oliver Neukum [EMAIL PROTECTED]
Caused-By : ?
Handled-By
On Tue, 2007-09-18 at 09:35 -0700, Mingming Cao wrote:
On Tue, 2007-09-18 at 10:04 +0100, Christoph Hellwig wrote:
On Mon, Sep 17, 2007 at 03:57:31PM -0700, Mingming Cao wrote:
Here is the incremental small cleanup patch.
Remove kamlloc usages in jbd/jbd2 and consistently use
On Wed, 2007-09-19 at 13:44 +0200, Oliver Neukum wrote:
Am Donnerstag 13 September 2007 schrieb Dave Kleikamp:
On Wed, 2007-09-12 at 18:58 +0200, Michal Piotrowski wrote:
Subject : umount triggers a warning in jfs and takes almost a
minute
References : http://lkml.org
On Wed, 2007-09-19 at 12:15 -0700, Mingming Cao wrote:
Here is the patch to clean up __GFP_NOFAIL flag in jbd/jbd2. In all
cases except one handles memory allocation failure so I get rid of those
GFP_NOFAIL flags.
Also, shouldn't we use GFP_KERNEL instead of GFP_NOFS flag for kmalloc
in
On Wed, 2007-09-19 at 14:26 -0500, Dave Kleikamp wrote:
On Wed, 2007-09-19 at 12:15 -0700, Mingming Cao wrote:
Here is the patch to clean up __GFP_NOFAIL flag in jbd/jbd2. In all
cases except one handles memory allocation failure so I get rid of those
GFP_NOFAIL flags.
Also
in the event of an error.
jfs_fill_super() returns any error incurred when getting the root inode
instead of EINVAL.
Signed-off-by: David Howells [EMAIL PROTECTED]
Acked-by: Dave Kleikamp [EMAIL PROTECTED]
---
fs/jfs/inode.c | 20
fs/jfs/jfs_inode.h |2 +-
fs
On Tue, 2007-10-02 at 13:32 +0100, David Howells wrote:
Zach Brown [EMAIL PROTECTED] wrote:
/* haha, continuing the fine tradition of terrible names in this api.. */
static inline void *PTR_PTR(void *err_ptr) {
BUG_ON(!IS_ERR(err_ptr) || !err_ptr);
return err_ptr;
}
How
On Tue, 2007-10-02 at 14:24 +0100, David Howells wrote:
Dave Kleikamp [EMAIL PROTECTED] wrote:
Of course, the cast is unnecessary,
The cast is necessary as the argument is a const pointer and the return type
is not.
Ah yes. I stand corrected.
--
David Kleikamp
IBM Linux Technology
of times vm_file_tail_unpack() have been called
3. Total size of file tails allocations
4. Number of file tail allocations
5. Bytes saved
Signed-off-by: Luiz Fernando N. Capitulino [EMAIL PROTECTED]
Signed-off-by: Dave Kleikamp [EMAIL PROTECTED]
---
mm/file_tail.c | 127
generic_file_aio_read can read directly from the tail. No need to unpack
Signed-off-by: Dave Kleikamp [EMAIL PROTECTED]
---
include/linux/vm_file_tail.h | 13 ++
mm/file_tail.c | 54 +++
mm/filemap.c |4
find_get_page() and find_lock_page() need to unpack the tail
If the page being sought corresponds to the tail, and the tail is packed
in the inode, the tail must be unpacked.
Signed-off-by: Dave Kleikamp [EMAIL PROTECTED]
---
mm/filemap.c |3 +++
1 file changed, 3 insertions(+)
diff -Nurp
Add tail to address space
Signed-off-by: Dave Kleikamp [EMAIL PROTECTED]
---
fs/inode.c |3 +++
include/linux/fs.h |4
mm/Kconfig |9 +
3 files changed, 16 insertions(+)
diff -Nurp linux000/fs/inode.c linux001/fs/inode.c
--- linux000/fs/inode.c 2007-11
Release tail when inode is freed
Signed-off-by: Dave Kleikamp [EMAIL PROTECTED]
---
fs/inode.c |2 ++
1 file changed, 2 insertions(+)
diff -Nurp linux002/fs/inode.c linux003/fs/inode.c
--- linux002/fs/inode.c 2007-11-08 10:49:46.0 -0600
+++ linux003/fs/inode.c 2007-11-08 10:49
-by: Dave Kleikamp [EMAIL PROTECTED]
---
include/linux/fs.h | 14 ++
mm/file_tail.c | 11 +++
2 files changed, 25 insertions(+)
diff -Nurp linux003/include/linux/fs.h linux004/include/linux/fs.h
--- linux003/include/linux/fs.h 2007-11-08 10:49:46.0 -0600
For readahead, leave data in tail
Don't unpack it until it's actually read.
Signed-off-by: Dave Kleikamp [EMAIL PROTECTED]
---
mm/readahead.c |5 +
1 file changed, 5 insertions(+)
diff -Nurp linux005/mm/readahead.c linux006/mm/readahead.c
--- linux005/mm/readahead.c 2007-11-07 08
and unpacked repeatedly. I also don't want to add too much overhead,
such as an extra scan of the inactive list.
Signed-off-by: Dave Kleikamp [EMAIL PROTECTED]
---
mm/vmscan.c |6 ++
1 file changed, 6 insertions(+)
diff -Nurp linux006/mm/vmscan.c linux007/mm/vmscan.c
--- linux006/mm
On Thu, 2008-01-24 at 20:34 +0100, Miklos Szeredi wrote:
plain text document attachment (jfs_opts.patch)
From: Miklos Szeredi [EMAIL PROTECTED]
Add iocharset= and errors= options to /proc/mounts for jfs
filesystems.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
Acked-by: Dave Kleikamp
On Thu, 2008-01-24 at 13:57 -0800, Andrew Morton wrote:
My usual algorithm here is to
1: queue all the patches and send the ones which have a maintainer to
that maintainer until he merges it.
2: If the patches have a dependency upon (say) a VFS patch then I'll
merge the VFS patch
On Sun, 2008-01-27 at 03:17 +0100, Andi Kleen wrote:
Convert jfs_ioctl over to not use the BKL. The only potential race
I could see was with two ioctls in parallel changing the flags
and losing the updates. Use the i_mutex to protect against this.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi
On Sun, 2008-01-27 at 03:17 +0100, Andi Kleen wrote:
The ioctls were already compatible except for the actual values so this
was fairly easy to do.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Added to the jfs git tree.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux
On Mon, 2008-01-28 at 12:33 -0600, Steve French wrote:
On Jan 28, 2008 2:17 AM, Andi Kleen [EMAIL PROTECTED] wrote:
I completely agree. If one thread writes A and another writes B then the
kernel should record either A or B, not ((A 0x) | (B
0x))
The
78 matches
Mail list logo
