On Mon, Feb 18, 2008 at 10:16:32AM -0500, Theodore Tso wrote:
> On Mon, Feb 18, 2008 at 04:02:36PM +0100, Tomasz Chmielewski wrote:
> > I tried to copy that filesystem once (when it was much smaller) with "rsync
> > -a -H", but after 3 days, rsync was still building an index and didn't copy
> > a
On Mon, Feb 18, 2008 at 09:16:41AM -0500, Theodore Tso wrote:
> ext3 tries to keep inodes in the same block group as their containing
> directory. If you have lots of hard links, obviously it can't really
> do that, especially since we don't have a good way at mkdir time to
> tell the filesystem,
Tomasz Chmielewski <[EMAIL PROTECTED]> writes:
>
> Is it normal to expect the write speed go down to only few dozens of
> kilobytes/s? Is it because of that many seeks? Can it be somehow
> optimized?
I have similar problems on my linux source partition which also
has a lot of hard linked files (a
KOSAKI Motohiro <[EMAIL PROTECTED]> writes:
>
> to be honest, I don't think at mem-cgroup until now.
There is not only mem-cgroup BTW, but also NUMA node restrictons from
NUMA memory policy. So this means a process might not be able to access
all memory.
-Andi
-
To unsubscribe from this list: sen
On Monday 28 January 2008 14:38:57 Alan Cox wrote:
> > Also worse really fixing it would be a major change to the VFS
> > because of the way ->read/write are defined :/
>
> I don't see a problem there. ->read and ->write update the passed pointer
> which is not the real f_pos anyway. Just the cop
On Monday 28 January 2008 13:56:05 Alan Cox wrote:
> > > No specific spec, just general quality of implementation.
> >
> > 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))
>
> Ag
> 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 problem is pretty nasty unfortunately. To solve it properly I think
the file_operations->read/write prototypes would need to be
On Monday 28 January 2008 06:33, Andrew Morton wrote:
> On Sun, 27 Jan 2008 03:17:09 +0100 (CET) Andi Kleen <[EMAIL PROTECTED]> wrote:
> > I checked ext3_ioctl and it looked largely safe to not be used
> > without BKL. So convert it over to unlocked_ioctl.
> >
>
On Monday 28 January 2008 05:13:09 Trond Myklebust wrote:
>
> On Mon, 2008-01-28 at 03:58 +0100, Andi Kleen wrote:
> > The problem is that it's not a race in who gets to do its thing first, but
> > a
> > parallel reader can actually see a corrupted value from the
> BTW. here is a patch I did a while back for minix. I know it isn't
> a big deal, but the work is done so I guess I should send it along.
Looks safe, although I'm surprised it actually gets around with such
little locking in general.
-Andi
-
To unsubscribe from this list: send the line "unsu
On Monday 28 January 2008 00:08:56 Trond Myklebust wrote:
>
> On Sun, 2008-01-27 at 16:18 -0600, Steve French wrote:
> > If two seeks overlap, can't you end up with an f_pos value that is
> > different than what either thread seeked to? or if you have a seek and
> > a read overlap can't you end up
On Sunday 27 January 2008 23:18:26 Steve French wrote:
> If two seeks overlap, can't you end up with an f_pos value that is
> different than what either thread seeked to?
Yes you can on 32bit. Especially during the 4GB wrap
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-f
On Sunday 27 January 2008 17:57:14 Steve French wrote:
> Don't you need to a spinlock/spinunlock(i_lock) or something similar
> (there isn't a spinlock in the file struct unfortunately) around the
> reads and writes from f_pos in fs/read_write.c in remote_llseek with
> your patch since the reads/wr
st one other flags change
that was lockless and could potentially lose updates.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
Documentation/filesystems/vfs.txt |5 -
fs/fcntl.c|6 +-
fs/ioctl.c|5 -
include/linux/fs
Here's another patch that was missing in the previous BKL-removal series.
No BKL needed in pipe_ioctl
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/fs/pipe.c
===
--- linux.orig/fs/pipe.c
+++ linux/fs/pipe.
ff-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ext4/dir.c |2 +-
fs/ext4/file.c |2 +-
fs/ext4/ioctl.c | 20 +++-
include/linux/ext4_fs.h |3 +--
4 files changed, 14 insertions(+), 13 deletions(-)
Index: linux/fs
None of the callers of this function does actually take the BKL
as far as I can see. So remove the comment refering to the BKL.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/jbd/recovery.c |2 +-
fs/jbd2/recovery.c |2 +-
2
There is no BKL held on entry in ->fsync nor in the low level ext3_sync_file.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ext3/dir.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/fs/e
cifs_ioctl doesn't seem to need the BKL for anything, so convert it over
to use unlocked_ioctl.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/cifs/cifsfs.c | 10 +-
fs/cifs/cifsfs.h |4 ++--
fs/cifs/ioctl.c |4 ++--
3 files changed, 9
As far as I can see there is nothing in ocfs2_ioctl that requires the BKL,
so use unlocked_ioctl
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ocfs2/file.c |4 ++--
fs/ocfs2/ioctl.c | 12 +++-
fs/ocfs2/ioctl.h |3 +--
3 files chan
Similar to the compat handlers of other file systems. The ioctls
are compatible except that they have different numbers.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/cifs/cifsfs.c | 15 +++
fs/cifs/cifsfs.h |2 ++
fs/cifs/ioctl.c
BKL is not hold in any of those
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ext4/dir.c |2 +-
fs/ext4/inode.c |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
Index: linux/fs/ext4
d NFS
take the BKL, but explicitely in their own source now.
I moved them all over in a single patch to avoid unbisectable sections.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/cifs/cifsfs
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
net/socket.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/net/socket.c
===
--- linux.orig/net/socket.c
+++ linux/net/so
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/fuse/dev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/fs/fuse/dev.c
===
--- linux.orig/fs/fuse/dev.c
+++ linux/fs/fuse
Not that it matters much, but it was easy.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/bad_inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/fs/bad_inode.c
===
--- linux.orig/fs/bad_i
tually and then the non unlocked async entry point could be dropped.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
Documentation/filesystems/vfs.txt |5 -
fs/fcntl.c|6 +-
fs/ioctl.c|5 -
include/linux/fs.h
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/pipe.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux/fs/pipe.c
===
--- linux.orig/fs/pipe.c
+++ linux/fs/pipe.c
@@ -788,7 +788,7 @@
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]>
---
fs/jfs/file.c |3 +++
fs/jfs/ioctl.c | 18 ++
fs/jfs/jfs_dinode.h |2 ++
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 Kleen <[EMAIL PROTECTED]>
---
fs/jfs/file.c
ff-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ext3/dir.c |2 +-
fs/ext3/file.c |2 +-
fs/ext3/ioctl.c | 21 +++--
include/linux/ext3_fs.h |3 +--
4 files changed, 14 insertions(+), 14 deletions(-)
Index: linux/fs
[Andrew: I believe this is -mm material for .25]
- Convert some more file systems (generally those who don't use the BKL
for anything except mount) to use unlocked_bkl.
- Implement BKL less fasync (see patch for the rationale)
This is currently a separate entry point, but since the number of fas
I checked ext2_ioctl and could not find anything in there that would
need the BKL. So convert it over to use unlocked_ioctl
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ext2/dir.c |2 +-
fs/ext2/ext2.h |3 +--
fs/ext2/file.c |4 ++--
fs/ext2/ioctl.c
No BKL used anywhere, so don't mention it.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/ext2/inode.c |1 -
1 file changed, 1 deletion(-)
Index: linux/fs/ext2/inode.c
===
--- linux.orig/fs/ext2/inode.c
+
Jens Axboe <[EMAIL PROTECTED]> writes:
>
> So how does it work? Instead of punting IO to a thread and passing it
> through the page cache, we instead attempt to send the IO directly to the
Great -- something like this was needed for a long time.
> - The file block mappings must not change while l
> The only problem I can see from an NFS perspective is with NFSv2/v3
> locking: unfortunately the protocol provides no way for the server to
> notify that a lock may not be granted after the client has been told to
> block. You would therefore have to bend the protocol rules by simply
> delaying r
Matthew Wilcox <[EMAIL PROTECTED]> writes:
>
> The blocked_list is a bit more complex since we need to check every lock
> on the blocked list, and would need to acquire all the sb_file_lock_locks
> to check this list consistently. I don't see a nice way to do this --
> particularly when you consid
"Jon Smirl" <[EMAIL PROTECTED]> writes:
> On 11/14/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
>> On Nov 13, 2007, at 7:04 PM, Jon Smirl wrote:
>> > Is it feasible to do something like this in the linux file system
>> > architecture?
>> >
>> > Beagle beats on my disk for an hour when I reboot. Of c
Jens Axboe <[EMAIL PROTECTED]> writes:
>
> Writing a small test module to exercise slub/slab in various ways
> (allocating from all cpus freeing from one, as described) should not be
> too hard. Perhaps that would be enough to find this performance
> discrepancy between slab and slub?
You could s
Christoph Lameter <[EMAIL PROTECTED]> writes:
It seems like a good idea simply because the same functionality
is already open coded in a couple of places and unifying
that would be a good thing. But ...
> The patchset provides this functionality in stages. Stage 1 introduces
> the basic fall bac
On Mon, Aug 13, 2007 at 10:24:52PM +0200, Michal Piotrowski wrote:
> On 13/08/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > Unclassified
> > >
> > > Subject : reset during bootup - 2.6.23-rc2 (git d23cf676)
> >
> &g
> Unclassified
>
> Subject : reset during bootup - 2.6.23-rc2 (git d23cf676)
This is already fixed in mainline
There is a real regression with failing builds on some old binutils on
x86-64 know, but I don't know how to fix it.
-Andi
-
To unsubscribe from this list: send the line "unsub
On Sun, Jun 24, 2007 at 01:18:42PM -0700, Arjan van de Ven wrote:
>
> > Hmm, could define a macro DECLARE_ATOMIC_BITMAP(maxbit) that expands to the
> > smallest
> > possible type for each architecture. And a couple of ugly casts for set_bit
> > et.al.
> > but those could be also hidden in macros
Nick Piggin <[EMAIL PROTECTED]> writes:
[haven't read everything, just commenting on something that caught my eye]
> +struct fsblock {
> + atomic_tcount;
> + union {
> + struct {
> + unsigned long flags; /* XXX: flags could be int for
> better p
Nick Piggin <[EMAIL PROTECTED]> writes:
>
> - Structure packing. A page gets a number of buffer heads that are
> allocated in a linked list. fsblocks are allocated contiguously, so
> cacheline footprint is smaller in the above situation.
It would be interesting to test if that makes a differe
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> What is not working, and how does this patch fix it?
FWIW i use nfs root regularly for testing kernels and it works
for me.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
> NILFS (a New Implementation of a Log-structured Filesystem) Version 2 have
> been available at the project website
>
> http://www.nilfs.org/
>
> If you are interested, please visit to our website.
Could you please give some information on the use cases
for this file
Matt Mackall <[EMAIL PROTECTED]> writes:
> This is a relatively simple scheme for making a filesystem with
> incremental online consistency checks of both data and metadata.
> Overhead can be well under 1% disk space and CPU overhead may also be
> very small, while greatly improving filesystem int
On Tuesday 24 April 2007 12:40:24 Jan Kara wrote:
> > One of my autoboot test clients gave me this during shutdown. It used
> > reiserfs and autofs and NFS heavily.
> Jeff has a fix for this bug so it should go away soon... Thanks for
> report anyway :).
Well I hit two more -- see other mails if
FYI,
This was a debugging kernel (preempt, slab debugging, lockdep etc. enabled)
running autotest and some other load on a 4 core Opteron system
There was also another lockdep warning before that which I'm sending
separately.
Looks like some memory corruption. Could be something else, but at le
===
[ INFO: possible circular locking dependency detected ]
2.6.21-rc5-git6 #44
---
perl/7968 is trying to acquire lock:
(&inode->i_mutex){--..}, at: []
reiserfs_file_release+0x109/0x2cc
but
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > Define a new fs flag FS_SAFE, which denotes, that unprivileged
> > mounting of this filesystem may not constitute a security problem.
> >
> > Since most filesystems have
One of my autoboot test clients gave me this during shutdown. It used
reiserfs and autofs and NFS heavily.
Unmounting file systems
BUG: Dentry 8100f3693a40{i=2352220,n=xattrs} still in use (1) [unmount of
reiserfs sda9]
[ cut here ]
kernel BUG at
/mnt/dm-2/newautoboo
> The vast majority of applications are not
> modified to be SELinux aware - only a small handful of security aware
> applications are modified.
All applications that can edit /etc/resolv.conf? That's nearly
everything. You yourself gave the example; I'm not making anything up.
-Andi (sensing a
> For SELinux to be effective it has to have a complete policy definition.
> This would prevent the OpenOffice access (unless OpenOffice is in the
> modify_resolv_conf_t domain) above.
This would mean no fully functional root user anymore. My understanding
is rather that at least in the Fedora de
On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote:
> Normal applications need zero modification under SELinux.
>
> Some applications which manage security may need to be made SELinux-aware,
Anything that can touch /etc/resolv.conf? That's potentially a lot of binaries
if you consider
Karl MacMillan <[EMAIL PROTECTED]> writes:
> No - the real fix is to change the applications or to run under a policy
> that confines all applications. Most of the problems with resolv.conf,
> mtab, etc. stem from admin processes (e.g., editors or shell scripts)
> all running under the same uncon
> It's nice to check for consistency though, so we're adding that. Profile
> loading is a trusted operation, at least so far, and so security wise we
> don't actually have to care --- if loading an invalid profile can bring down
> the system, then that's no worse than an arbitrary module that cr
[EMAIL PROTECTED] writes:
[didn't review code fully, just some stuff I noticed]
> +
> +struct aa_dfa {
> + struct table_header *tables[YYTD_ID_NXT];
> +};
If that is passed in from user space you would need special compat
code for 64bit kernels who support 32bit userland.
Better to avoid poi
Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
>
> aio_sendfile_path() is essentially aio_sendfile(), except that it takes
> source filename as parameter, has a pointer to private header
> and its size (which allows to send header and file's content in one syscall
> instead of three (open, send, sen
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> So the second part of the problem is to somehow limit the number of
> dentries used. Not easy...
OpenVZ has some existing work in this area to separate their virtual machines.
I assume they will eventually submit it.
-Andi
-
To unsubscribe from thi
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
> > > possibly gain (or vice versa)
> > >
> > > - Relative merits of the two offerings
> >
> > You missed the important one - people actively use it and have been for
> >
On Thu, May 03, 2001 at 06:03:07PM -0700, Jeremy Allison wrote:
> The only thing we need to fix (IMHO) is the close(dup(fd)) "bug",
> which I have yet to see any application treat as anything other
> than a spec. bug that must be worked around.
I don't think it's a bug right now; not dropping the
On Thu, May 03, 2001 at 08:36:13AM +0100, Matthew Wilcox wrote:
> I'll get to it this weekend then. Should be a relatively simple patch.
Just don't forget to add a per user ulimit for it and probably an admin
tool like ipcs.
> Are there any other semantics you want changing from the POSIX lock?
On Mon, Apr 30, 2001 at 12:39:23PM -0600, Matthew Wilcox wrote:
> * All filesystems will fill in their ->lock method.
Why when a common stub should work for 90% of them? Please keep
global search-and-edit operation low when not absolutely possible.
> * Local filesystems should all use
On Sun, Mar 11, 2001 at 04:55:24AM -0500, Alexander Viro wrote:
>
>
> On Sun, 11 Mar 2001, Andi Kleen wrote:
>
> > On Sat, Mar 10, 2001 at 08:44:41PM -0500, Alexander Viro wrote:
> > > Too many places are using ->i_dev right now to eliminate ->i_dev.
> &
On Sat, Mar 10, 2001 at 08:44:41PM -0500, Alexander Viro wrote:
> Too many places are using ->i_dev right now to eliminate ->i_dev.
> Yes, it should eventually go away (and icache should work by ->i_sb/->i_ino
> instead of ->i_dev/->i_ino). ->i_dev should eventually go away, but that
> was too la
On Thu, Mar 08, 2001 at 03:48:08PM +, Matthew Wilcox wrote:
>
> Someone tell me if my chain of reasoning is wrong here...
>
> (1) The only way to get a `struct file' is to call get_empty_filp()
There is code that creates private struct files without calling get_empty_filp()
NFS comes to mi
On Wed, Jan 24, 2001 at 11:00:41AM -0500, Jeff Darcy wrote:
> From: "Andi Kleen" <[EMAIL PROTECTED]>
> > Does this mean that unwriten extents are supported now in pagebuf?
> Otherwise
> > this ioctl would need to prezero the disks blocks to prevent old data
&g
Quick question.
On Wed, Jan 24, 2001 at 09:20:43AM -0600, Steve Lord wrote:
> What XFS also has is an ioctl to preallocate disk space, there is very
> little documentation on this (none), but if you look in the file
> cmd/xfstests/src/randholes.c you will see an ioctl like this:
>
> struct flock
On Wed, Oct 04, 2000 at 01:47:28PM -0400, Ken Hirsch wrote:
>
> The advantages I see are that database systems and other resource managers
> would have much less complicated buffering logic, that the data would not be
> double-buffered, that the LRU algorithm would be more accurate (there was a
>
On Sun, Sep 10, 2000 at 01:18:40PM -0700, Ion Badulescu wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > Can I ask a stupid question: why do we pass a pointer to the file
> > position along with the file when calling read/write methods as in:
> >
> > read(file, buf, count, &file->f_pos)
>
72 matches
Mail list logo
