remount with open files
Hello, we have a SLES8 system with kernel 2.4.19-64GB-SMP and would like to add ACLs to the files system. As far as I can see the ACL options are compoled into the kernel. Is it possible to add the acl option to the /etc/fstab entry and then remount the filesystem with -o remount even with open files ? When the remount is done do I have to starta another program or so or is this all I have to do ? Thanks Andreas
Re: vs-6030
Hello On Mon, 2006-07-17 at 18:30 +0200, Adrian Ulrich wrote: Would the system crash if you dd to another directory of the filesystem? Writing/dd'ing to other directories (= *not* subdirectories of the homedir) worked fine. Would you please recompile with reiserfs debug on and crash again and send us all kernel output related to the crash? Hmm.. The owner of the System has already removed the broken directory :-/ .. All i've got is a metadump of the FS .. Sorry.. ok, where can I download it from? -- Adrian
Re: reiser4: possible circular locking dependency
Hello
On Sun, 2006-07-16 at 12:24 +0200, Laurent Riffard wrote:
Hello,
I just got this warning:
===
[ INFO: possible circular locking dependency detected ]
---
nautilus/3229 is trying to acquire lock:
(txnh-hlock){--..}, at: [e0c8e09b] txn_end+0x191/0x368 [reiser4]
but task is already holding lock:
(atom-alock){--..}, at: [e0c8a640] txnh_get_atom+0xf6/0x39e [reiser4]
which lock already depends on the new lock.
lock validator is too severe. I guess that it thinks that
txnh_get_atom() breaks lock ordering. This warning can be ignored.
the existing dependency chain (in reverse order) is:
- #1 (atom-alock){--..}:
[c012d1a7] lock_acquire+0x60/0x80
[c02924f8] _spin_lock+0x19/0x28
[e0c8bbd7] try_capture+0x7cf/0x1cd7 [reiser4]
[e0c786e1] longterm_lock_znode+0x427/0x84f [reiser4]
[e0ca7fcb] seal_validate+0x221/0x5ee [reiser4]
[e0cbefb1] update_sd+0x1c5/0x6a0 [reiser4]
[e0cbfa37] write_sd_by_inode_common+0x5ab/0x61a [reiser4]
[e0cb428b] reiser4_update_sd+0x83/0x8c [reiser4]
[e0caba2f] reiser4_dirty_inode+0xea/0x143 [reiser4]
[c017062d] __mark_inode_dirty+0x2a/0x156
[c0169650] touch_atime+0x89/0x91
[e0cbe010] readdir_common+0x7da/0x848 [reiser4]
[c0162c4f] vfs_readdir+0x4e/0x7a
[c0162cd9] sys_getdents64+0x5e/0xa0
[c0102c2d] sysenter_past_esp+0x56/0x8d
- #0 (txnh-hlock){--..}:
[c012d1a7] lock_acquire+0x60/0x80
[c02924f8] _spin_lock+0x19/0x28
[e0c8e09b] txn_end+0x191/0x368 [reiser4]
[e0c7f97d] reiser4_exit_context+0x1c2/0x571 [reiser4]
[e0cbe02e] readdir_common+0x7f8/0x848 [reiser4]
[c0162c4f] vfs_readdir+0x4e/0x7a
[c0162cd9] sys_getdents64+0x5e/0xa0
[c0102c2d] sysenter_past_esp+0x56/0x8d
other info that might help us debug this:
2 locks held by nautilus/3229:
#0: (inode-i_mutex){--..}, at: [c02913aa] mutex_lock+0x21/0x24
#1: (atom-alock){--..}, at: [e0c8a640] txnh_get_atom+0xf6/0x39e
[reiser4]
stack backtrace:
[c0104db5] show_trace+0xd/0x10
[c0104dd1] dump_stack+0x19/0x1c
[c012bfda] print_circular_bug_tail+0x59/0x64
[c012cfb6] __lock_acquire+0x814/0x9a5
[c012d1a7] lock_acquire+0x60/0x80
[c02924f8] _spin_lock+0x19/0x28
[e0c8e09b] txn_end+0x191/0x368 [reiser4]
[e0c7f97d] reiser4_exit_context+0x1c2/0x571 [reiser4]
[e0cbe02e] readdir_common+0x7f8/0x848 [reiser4]
[c0162c4f] vfs_readdir+0x4e/0x7a
[c0162cd9] sys_getdents64+0x5e/0xa0
[c0102c2d] sysenter_past_esp+0x56/0x8d
I'm running 2.6.18-rc1-mm2 with a few patches:
- drivers-base-check-errors-fix.patch (hot-fixes)
- annotate-pktcdvd-natural-device-hierarchy.patch (from Arjan van de Ven)
- blkdev_get_partition.patch (from Peter Osterlund)
.config is attached
--
laurent
plain text document attachment (config-2.6.18-rc1-mm2)
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.18-rc1-mm2
# Sun Jul 16 12:05:34 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SWAP_PREFETCH=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
CONFIG_SYSCTL=y
CONFIG_SYSCTL_SYSCALL=y
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=
CONFIG_KLIBC_ERRLIST=y
CONFIG_KLIBC_ZLIB=y
CONFIG_UID16=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_RT_MUTEXES=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is
Re: reiser4 OOPSes and panics when out of memory
Hello On Tue, 2006-07-18 at 00:52 -0600, Jake Maciejewski wrote: Thanks for the patch, but I can still reproduce the problem. I've been running the attached program to try to speed up the testing process a bit. Interrupting and restarting the compilation loop also seems to help. ok If I had hours to wait, it would probably crash eventually without additional encouragement, but I'm doing everything as an unprivileged user, so I don't think my tests are unreasonable. Anyway, I'm still getting a panic with debug enabled: reiser4 panicked cowardly: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]: Kernel panic - not syncing: reiser4[find(16411)]: reiser4_dirty_inode (fs/reiser4/super_ops.c:173)[]: The attached patch should fix the above. Without debug enabled I've seen: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages1.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--fix.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check_after_--fix.txt.gz but usually I get: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages3.txt.gz with no corruption (although I've been rebooting before complete failure). On Mon, 2006-07-17 at 21:38 +0400, Vladimir V. Saveliev wrote: Hello On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote: Hello On Sun, 2006-07-16 at 12:44 -0500, [EMAIL PROTECTED] wrote: Has my previous post (http://marc.theaimsgroup.com/?l=reiserfsm=115259665831650w=2) been overlooked, or have I not provided enough information? Do I need to reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches? please try the attached patch. your test crashes reiser4 on my test box. I hope to get a patch ready later today. Not sure that I got the same problem as you, though. We will see. The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic reiser4 on my amd64 machine (haven't tried x86 yet) by using all available physical memory. readdir has to txn_restart, therefore, grab space for stat data update has to be forced --- commit f1cea9c0a8db0977077d54562677514d6d736690 tree 95479706299276d7c23efd337216501b0dfd69c2 parent bbf99f71c140d7758a6223a557fa4a4d2b5c384e author Vladimir V. Saveliev [EMAIL PROTECTED] Tue, 18 Jul 2006 18:13:05 +0400 committer Vladimir V. Saveliev [EMAIL PROTECTED] Tue, 18 Jul 2006 18:13:05 +0400 plugin/file_ops_readdir.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/plugin/file_ops_readdir.c b/plugin/file_ops_readdir.c index 04ada21..dfdb68d 100644 --- a/plugin/file_ops_readdir.c +++ b/plugin/file_ops_readdir.c @@ -629,7 +629,7 @@ int readdir_common(struct file *f /* dir detach_fsdata(f); /* try to update directory's atime */ - if (reiser4_grab_space(inode_file_plugin(inode)-estimate.update(inode), + if (reiser4_grab_space_force(inode_file_plugin(inode)-estimate.update(inode), BA_CAN_COMMIT) != 0) warning(, failed to update atime on readdir: %llu, get_inode_oid(inode));
Re: [PATCH] reiserfs: fix handling of device names with /'s in them
Try v4. My original xattr implementation added another item type, but oh -- wait -- it turns out that the file system isn't quite as extensible as claimed.. or, well, AT ALL. Adding another item results in an incompatible file system change that when mounted on another system, will panic the node. That's friendly! There's not even any way to identify which items are in use on a particular file system to issue a warning/error on mount. Outstanding job architecting there. Well, if you had an obsessive desire to not use V4, you could fix this in V3 instead. Might be easier to use V4... Users wanted ACLs and xattrs on reiser3, but you said, wait for v4, it'll be out soon, and it'll have them. That was 4 years ago. Reiser4 still isn't completely stable My word here is done: While reiserfs3 actually got ACLs, xattrs and quota support by now, reiser4 still lacks them. Something must be very wrong to suggest V4; at least when it comes to these three things. Jan Engelhardt --
Re: remount with open files
hello, On Tuesday 18 July 2006 10:40, Andreas Moroder wrote: Hello, we have a SLES8 system with kernel 2.4.19-64GB-SMP and would like to add ACLs to the files system. As far as I can see the ACL options are compoled into the kernel. Is it possible to add the acl option to the /etc/fstab entry and then remount the filesystem with -o remount even with open files ? When the remount is done do I have to starta another program or so or is this all I have to do ? I tried it with suse 10.1 / Linux-2.6.16.13 and it works fine. a reiserfs volume was mounted under /mnt/testfs, then I did mount -o remount,acl /mnt/testfs and setfacl started to work. I even tried it with fs with one open file. it worked. -- Alex.
Re: remount with open files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Moroder wrote:
Hello,
we have a SLES8 system with kernel 2.4.19-64GB-SMP and would like to add
ACLs to the files system. As far as I can see the ACL options are
compoled into the kernel. Is it possible to add the acl option to the
/etc/fstab entry and then remount the filesystem with -o remount even
with open files ?
When the remount is done do I have to starta another program or so or is
this all I have to do ?
Yes, ACLs are safe to enable and disable on-the-fly with -oremount,{,no}acl.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFEvRelLPWxlyuTD7IRApAwAJ4+RNlJmHj5P0X21iZDc3HnGRGVmgCfee9s
4EM3hm3HrblEkqMXw8xBAPc=
=2Kbs
-END PGP SIGNATURE-
Re: Re: [PATCH] reiserfs: fix handling of device names with /'s in them
On 7/17/06, Hans Reiser [EMAIL PROTECTED] wrote: Replacing / with ! is hideous. Someone added a nifty elegance to block device naming, and you are desecrating it. You're free to send a patch to fix it all, you know. Until then, lets make reiserfs consistent with rest of the kernel, ok?
2.6.17 patch is in testing now
It contains 5 bug fixes. If testing goes well we will release it tomorrow.It is listed below in case you feel like helping to test, it works on vs's workstation ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.17/reiser4-for-2.6.17-1.patch.gz Apologies to our users that this took a while Hans
backporting?
I also wanted to say that I'm back -- all problems with my mailserver bouncing messages should be fixed now. But I do have a legitimate question: I get my Reiser4 as the reiser4-for-2.6 patches. Do new versions ever get backported to older kernel versions? This is not a feature request -- if there's no backport, I'll do without. I'm currently stuck on 2.6.13.4 because of a network driver, but it's probably easier to fix a network driver than to backport a filesystem.
