On Tue, 2007-07-10 at 23:18 -0700, Andrew Morton wrote:
On Sun, 01 Jul 2007 03:38:51 -0400 Mingming Cao [EMAIL PROTECTED] wrote:
Subject: [EXT4 set 9][PATCH 4/5]Morecleanups:ext4_extent_compilation_fixes
Date: Sun, 01 Jul 2007 03:38:51 -0400
Sender: [EMAIL PROTECTED]
Organization:
On Jul 15 2007 23:23, Al Viro wrote:
On Sun, Jul 15, 2007 at 02:13:21PM -0700, Nicholas Miell wrote:
I suspect he was asking for
int getxattrat(int fd, const char *path, const char *name, void *value,
size_t size, int flags)
int setxattrat(int fd, const char *path, const
On Mon, Jul 16, 2007 at 09:56:10AM +0200, Jan Engelhardt wrote:
Just one question: what the bleeding hell for? Not that the rest of
..at() family made any damn sense as an interface...
fd1 = open(dir1, O_DIRECTORY):
fd2 = open(dir2, O_DIRECTORY);
system(mount -t tmpfs none dir1);
On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
Index: linux-2.6.22-rc4/include/linux/jbd2.h
===
--- linux-2.6.22-rc4.orig/include/linux/jbd2.h 2007-06-11
16:16:18.0 -0700
+++
On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
On Sun, 01 Jul 2007 03:36:22 -0400
Mingming Cao [EMAIL PROTECTED] wrote:
with the patch all headers are checked. the code should become
more resistant to on-disk corruptions. needless BUG_ON() have
been removed. please, review for
On Tue, 2007-07-10 at 19:31 -0700, Andrew Morton wrote:
On Sun, 01 Jul 2007 03:38:10 -0400 Mingming Cao [EMAIL PROTECTED] wrote:
[PATCH] jbd2 stats through procfs
The patch below updates the jbd stats patch to 2.6.20/jbd2.
The initial patch was posted by Alex Tomas in December 2005
On Tue, 2007-07-10 at 21:42 -0700, Andrew Morton wrote:
On Tue, 10 Jul 2007 23:21:49 -0400 Cédric Augonnet [EMAIL PROTECTED]
wrote:
2007/7/10, Andrew Morton [EMAIL PROTECTED]:
Hi all,
+ size = sizeof(struct transaction_stats_s);
+ s-stats = kmalloc(size, GFP_KERNEL);
Jan Engelhardt wrote:
fd1 = open(dir1, O_DIRECTORY):
fd2 = open(dir2, O_DIRECTORY);
system(mount -t tmpfs none dir1);
system(mount -t tmpfs none dir2);
openat(fd1, file1, O_RDWR | O_CREAT);
openat(fd2, file2, O_RDWR | O_CREAT);
If you have a better way to accomplish this, let me know. :)
fd1 = open(dir1, O_DIRECTORY):
fd2 = open(dir2, O_DIRECTORY);
system(mount -t tmpfs none dir1);
system(mount -t tmpfs none dir2);
openat(fd1, file1, O_RDWR | O_CREAT);
openat(fd2, file2, O_RDWR | O_CREAT);
If you have a better way to accomplish this, let me know. :)
This
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
This should work:
fchdir(fd1);
open(file1, O_RDWR | O_CREAT);
fchdir(fd2);
open(file2, O_RDWR | O_CREAT);
This is not thread-safe.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße
Miklos Szeredi wrote:
The *at() thing basically gives you the advantages of a CWD without
the disadvantages.
For example it could be useful to implement the functionality of
find(1) as a library interface.
What the *at() interfaces really do is fix/paper over a longstanding
wart in
H. Peter Anvin wrote:
Miklos Szeredi wrote:
The *at() thing basically gives you the advantages of a CWD without
the disadvantages.
For example it could be useful to implement the functionality of
find(1) as a library interface.
What the *at() interfaces really do is fix/paper over a
On 7/16/07, Al Boldi [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Or just cp -al to create multiple trees at (almost) no disk cost
that won't interfere with each other in any way, and makes the
development process / generating patchsets trifle easier as well ...
That would be correct if
On Mon, 16 July 2007 22:14:41 +0530, Satyam Sharma wrote:
On 7/16/07, Al Boldi [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Or just cp -al to create multiple trees at (almost) no disk cost
that won't interfere with each other in any way, and makes the
development process / generating
Jörn Engel wrote:
On Mon, 16 July 2007 22:14:41 +0530, Satyam Sharma wrote:
On 7/16/07, Al Boldi [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Or just cp -al to create multiple trees at (almost) no disk cost
that won't interfere with each other in any way, and makes the
development
Bryan J. Smith wrote:
Off-topic, advocacy-level response ...
On Mon, 2007-07-16 at 11:43 -0400, Joshua Baker-LePain wrote:
I do so wish that RedHat shared this view...
I've been trying to convince them since Red Hat Linux 7 (and, later, 9)
that they need to realize the limits of Ext3 at
On Mon, Jul 16, 2007 at 08:40:00PM +0300, Al Boldi wrote:
XFS surely rocks, but it's missing one critical component: data=ordered
And that's one component that's just too critical to overlook for an
enterprise environment that is built on data-integrity over performance.
So that's the
Jeff Garzik wrote:
What the *at() interfaces really do is fix/paper over a longstanding
wart in Unix: the cwd really should have been a standard file descriptor
(like stdin/stdout/stderr) instead of a magic piece of state maintained
in kernel space.
It's more than a wart, IMO. *at()
Matthew Wilcox wrote:
On Mon, Jul 16, 2007 at 08:40:00PM +0300, Al Boldi wrote:
XFS surely rocks, but it's missing one critical component: data=ordered
And that's one component that's just too critical to overlook for an
enterprise environment that is built on data-integrity over
On Mon, 2007-07-16 at 11:48 -0600, Matthew Wilcox wrote:
Wow, thanks for bringing an advocacy thread onto linux-fsdevel. Just what
we wanted. Do you have any insight into how to get the data=ordered
onto the VFS level? Because to me, that sounds like pure nonsense.
First off, I have no idea
/proc/mounts in its current state fail to disambiguate bind mounts, especially
when the bind mount is subrooted. Also it does not capture propagation state of
the mounts(shared-subtree). The following patch addresses the problem.
The following additional fields to /proc/mounts are added.
On Mon, Jul 16, 2007 at 09:28:08PM +0300, Al Boldi wrote:
Well, conceptually it sounds like a piece of cake, technically your guess is
as good as mine. IIRC, akpm once mentioned something like this.
How much have you looked at the VFS? There's nothing journalling-related
in the VFS right
H. Peter Anvin wrote:
Jeff Garzik wrote:
What the *at() interfaces really do is fix/paper over a longstanding
wart in Unix: the cwd really should have been a standard file descriptor
(like stdin/stdout/stderr) instead of a magic piece of state maintained
in kernel space.
It's more than a wart,
Jeff Garzik wrote:
Well, as Jeremy pointed out, in the absence of threads you can do the
same thing with fchdir(), however, that's much more of a hack.
My posixutils project (coreutils replacement) used fchdir(2), but that
still doesn't get you 100% race-free. It gets you close, yes.
I
On Mon, 16 July 2007 20:23:04 +0300, Al Boldi wrote:
Jörn Engel wrote:
The only place that can ensure to always break the
link is the kernel. Which is why I wrote the cowlink patches some years
back.
Can you post a patch against 2.6.22?
I can and probably will.
The still need a
I have seen various requests from users to disable part of the CIFS
Unix Extensions on mount (in some cases fall back to the more
primitive Windows behavior) but am wondering how far down this line of
thought I should go ... how many mount options to add to cifs and is
there a precedent in other
I would like opinions on how to handle a specific use question ...
if the user has mounted e.g. \\server1\shareA (e.g. on a Samba
server) using defaults (and thus gotten support for the Unix
Extensions, but then does a second mount trying to disable Unix
Extensions (e.g. mount -t cifs
On Fri, 2007-07-13 at 02:05 -0700, Andrew Morton wrote:
On Tue, 10 Jul 2007 16:32:47 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
+ brelse(bh);
+ up_write(EXT4_I(inode)-xattr_sem);
+ return error;
+}
+
We're doing GFP_KERNEL memory allocations while holding xattr_sem. This
On Jul 16, 2007 16:52 -0700, Mingming Cao wrote:
I am not sure why we need GFP_KERNEL flag here. I think we should use
GFP_NOFS instead. The following patch use the GFP_NOFS flag, as well as
fixing memory leak issue introduced by the ext4 expand inode extra isize
patch.
Fixing memory
On Mon, 2007-07-16 at 18:06 -0600, Andreas Dilger wrote:
On Jul 16, 2007 16:52 -0700, Mingming Cao wrote:
I am not sure why we need GFP_KERNEL flag here. I think we should use
GFP_NOFS instead. The following patch use the GFP_NOFS flag, as well as
fixing memory leak issue introduced by the
On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
On Sun, 01 Jul 2007 03:36:56 -0400
Mingming Cao [EMAIL PROTECTED] wrote:
This patch is a spinoff of the old nanosecond patches.
I don't know what the old nanosecond patches are. A link to a suitable
changlog for those patches would
31 matches
Mail list logo
