On Mon, Feb 18, 2008 at 04:57:25PM +0100, Andi Kleen wrote:
Use cp
or a tar pipeline to move the files.
Are you sure cp handles hardlinks correctly? I know tar does,
but I have my doubts about cp.
I *think* GNU cp does the right thing with --preserve=links. I'm not
100% sure, though ---
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
any file.
Theodore Tso schrieb:
Are there better choices than ext3 for a filesystem with lots of hardlinks?
ext4, once it's ready? xfs?
All filesystems are going to have problems keeping inodes close to
directories when you have huge numbers of hard links.
I'd really need to know exactly what kind of
On Mon, Feb 18, 2008 at 05:16:55PM +0100, Tomasz Chmielewski wrote:
Theodore Tso schrieb:
I'd really need to know exactly what kind of operations you were
trying to do that were causing problems before I could say for sure.
Yes, you said you were removing unneeded files, but how were you
There is a number of pseudo file systems in the kernel
that are basically copies of debugfs, all implementing the
same boilerplate code, just with different bugs.
This adds yet another copy to the kernel in the libfs directory,
with generalized helpers that can be used by any of them.
The most
With libfs turning into a larger subsystem, it makes
sense to have a separate header that is not included
by the low-level vfs code.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6/fs/debugfs/inode.c
===
---
With the new simple_fs_type in place, securityfs practically
becomes a nop and we just need to leave code around to manage
its mount point.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6/security/inode.c
===
---
Half of the usbfs code is the same as debugfs, so we can
replace it now with calls to the generic libfs versions.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6/drivers/usb/core/inode.c
===
---
Consolidate all super block manipulation code in libfs in a single
source file.
Signed-off-by: Arnd Bergman [EMAIL PROTECTED]
Index: linux-2.6/fs/libfs.c
===
--- linux-2.6.orig/fs/libfs.c
+++ linux-2.6/fs/libfs.c
@@ -12,63 +12,6 @@
Consolidate all dentry manipulation code in libfs in a single
source file.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6/fs/libfs.c
===
--- linux-2.6.orig/fs/libfs.c
+++ linux-2.6/fs/libfs.c
@@ -12,188 +12,6 @@
The file operations in debugfs are rather generic and can
be used by other file systems, so it can be interesting to
include them in libfs, with more generic names, and exported
to modules.
This patch adds a new copy of these operations to libfs,
so that the debugfs version can later be cut down.
I noticed that there is a lot of duplication in pseudo
file systems, so I started looking into how to consolidate
them. I ended up with a largish rework of the structure
of libfs and moving almost all of debugfs in there as well.
As an example, I also have patches that reduce debugfs,
securityfs
With most of debugfs now copied to generic code in libfs,
we can remove the original copy and replace it with thin
wrappers around libfs.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6/fs/Kconfig
===
---
Consolidate all file manipulation code in libfs in a single
source file.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6/fs/libfs.c
===
--- linux-2.6.orig/fs/libfs.c
+++ linux-2.6/fs/libfs.c
@@ -421,165 +421,6 @@
Consolidate all inode manipulation code in libfs in a single
source file.
Signed-off-by: Arnd Bergman [EMAIL PROTECTED]
Index: linux-2.6/fs/libfs.c
===
--- linux-2.6.orig/fs/libfs.c
+++ linux-2.6/fs/libfs.c
@@ -12,78 +12,6 @@
Consolidate all address space manipulation code in libfs in a single
source file.
Signed-off-by: Arnd Bergman [EMAIL PROTECTED]
Index: linux-2.6/fs/libfs.c
===
--- linux-2.6.orig/fs/libfs.c
+++ /dev/null
@@ -1,116 +0,0 @@
-/*
- *
The patch looks fine - but since it does not set obj_type any more - I
want to think about it a little more since it may be useful coming
back from the open path (although the mode is probably good enough).
jra added support to Samba for a new POSIX open/create/mkdir request
(which we only use for
Hi,
Don't you remember the topic solid state drive access and context
switching [1].
I want to measure it is really better performance on SSD?
To write it on ssd synchronously, I hacked the
'generic_make_request()' [2] and got following results.
# echo 3 /proc/sys/vm/drop_caches
# tiotest -f
Hi Paul,
Thank you for wonderful interestings comment.
your comment is really nice.
I was HPC guy with large NUMA box at past.
I promise i don't ignroe hpc user.
but unfortunately I didn't have experience of use CPUSET
because at that point, it was under development yet.
I hope discuss you
19 matches
Mail list logo
