xfs Warnings in syslog
Hi My syslog and dmesg are being filled with the Warnings attached. Looking at todays syslog I got up to 1101 of these warnings in the time from 10:50 to 11:13 (and only in that time, else the log was clean). I found them on all four of my OSD hosts, all at about the same time. I'm running kernel 3.2.0-4-amd64 on a debian 7.0. Ceph is on version 0.67.4. I have got 15 OSDs per OSD Host. Ceph does not really seem to care about this, so I'm not sure what it is all about… Still they are warnings in syslog and I hope you guys can tell me what went wrong here and what I can do about it? Thank you Niklas Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388018] [ cut here ] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388030] WARNING: at /build/linux-s5x2oE/linux-3.2.46/fs/xfs/xfs_aops.c:1091 xfs_vm_releasepage+0x76/0x8e [xfs]() Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388034] Hardware name: X9DR3-F Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388036] Modules linked in: xfs autofs4 nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ext3 jbd loop acpi_cpufreq mperf coretemp crc32c_intel ghash_clmulni_intel snd_pcm aesni_intel snd_page_alloc aes_x86_64 snd_timer aes_generic s nd cryptd soundcore pcspkr sb_edac joydev evdev edac_core iTCO_wdt i2c_i801 iTCO_vendor_support i2c_core ioatdma processor thermal_sys container button ext4 crc16 jbd2 mbcache usbhid hid ses enclosure sg sd_mod crc_t10dif megaraid_sas ehci_hcd usbcore isci libsas usb_common liba ta ixgbe mdio scsi_transport_sas scsi_mod igb dca [last unloaded: scsi_wait_scan] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388093] Pid: 3459605, comm: ceph-osd Tainted: GW3.2.0-4-amd64 #1 Debian 3.2.46-1 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388096] Call Trace: Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388102] [81046b75] ? warn_slowpath_common+0x78/0x8c Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388115] [a048b98c] ? xfs_vm_releasepage+0x76/0x8e [xfs] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388122] [810bedc5] ? invalidate_inode_page+0x5e/0x80 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388129] [810bee5d] ? invalidate_mapping_pages+0x76/0x102 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388135] [810b7b83] ? sys_fadvise64_64+0x19f/0x1e2 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388140] [81353b52] ? system_call_fastpath+0x16/0x1b Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388144] ---[ end trace e9640ed6f82f066d ]--- -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ceph: add acl for cephfs
v2: remove some redundant code in ceph_setattr()
Signed-off-by: Guangliang Zhao lucienc...@gmail.com
---
fs/ceph/Kconfig | 13 +++
fs/ceph/Makefile |1 +
fs/ceph/acl.c| 286 ++
fs/ceph/dir.c|5 +
fs/ceph/inode.c | 10 ++
fs/ceph/super.c |4 +
fs/ceph/super.h | 31 ++
fs/ceph/xattr.c | 60 +---
8 files changed, 398 insertions(+), 12 deletions(-)
create mode 100644 fs/ceph/acl.c
diff --git a/fs/ceph/Kconfig b/fs/ceph/Kconfig
index ac9a2ef..264e9bf 100644
--- a/fs/ceph/Kconfig
+++ b/fs/ceph/Kconfig
@@ -25,3 +25,16 @@ config CEPH_FSCACHE
caching support for Ceph clients using FS-Cache
endif
+
+config CEPH_FS_POSIX_ACL
+ bool Ceph POSIX Access Control Lists
+ depends on CEPH_FS
+ select FS_POSIX_ACL
+ help
+ POSIX Access Control Lists (ACLs) support permissions for users and
+ groups beyond the owner/group/world scheme.
+
+ To learn more about Access Control Lists, visit the POSIX ACLs for
+ Linux website http://acl.bestbits.at/.
+
+ If you don't know what Access Control Lists are, say N
diff --git a/fs/ceph/Makefile b/fs/ceph/Makefile
index 32e3010..85a4230 100644
--- a/fs/ceph/Makefile
+++ b/fs/ceph/Makefile
@@ -10,3 +10,4 @@ ceph-y := super.o inode.o dir.o file.o locks.o addr.o ioctl.o
\
debugfs.o
ceph-$(CONFIG_CEPH_FSCACHE) += cache.o
+ceph-$(CONFIG_CEPH_FS_POSIX_ACL) += acl.o
diff --git a/fs/ceph/acl.c b/fs/ceph/acl.c
new file mode 100644
index 000..4d0c5e1
--- /dev/null
+++ b/fs/ceph/acl.c
@@ -0,0 +1,286 @@
+/*
+ * linux/fs/ceph/acl.c
+ *
+ * Copyright (C) 2013 Guangliang Zhao, lucienc...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include linux/ceph/ceph_debug.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/xattr.h
+#include linux/posix_acl_xattr.h
+#include linux/posix_acl.h
+#include linux/sched.h
+#include linux/slab.h
+
+#include super.h
+
+struct posix_acl *ceph_get_acl(struct inode *inode, int type)
+{
+ int size;
+ const char *name;
+ char *value = NULL;
+ struct posix_acl *acl;
+
+ if (!IS_POSIXACL(inode))
+ return NULL;
+
+ acl = get_cached_acl(inode, type);
+ if (acl != ACL_NOT_CACHED)
+ return acl;
+
+ switch (type) {
+ case ACL_TYPE_ACCESS:
+ name = POSIX_ACL_XATTR_ACCESS;
+ break;
+ case ACL_TYPE_DEFAULT:
+ name = POSIX_ACL_XATTR_DEFAULT;
+ break;
+ default:
+ BUG();
+ }
+
+ size = __ceph_getxattr(inode, name, , 0);
+ if (size 0) {
+ value = kzalloc(size, GFP_NOFS);
+ if (!value)
+ return ERR_PTR(-ENOMEM);
+ size = __ceph_getxattr(inode, name, value, size);
+ }
+
+ if (size 0)
+ acl = posix_acl_from_xattr(init_user_ns, value, size);
+ else if (size == -ERANGE || size == -ENODATA || size == 0)
+ acl = NULL;
+ else
+ acl = ERR_PTR(-EIO);
+
+ kfree(value);
+
+ if (!IS_ERR(acl))
+ set_cached_acl(inode, type, acl);
+
+ return acl;
+}
+
+static int ceph_set_acl(struct dentry *dentry, struct inode *inode,
+ struct posix_acl *acl, int type)
+{
+ int ret = 0, size = 0;
+ const char *name = NULL;
+ char *value = NULL;
+
+ if (acl) {
+ ret = posix_acl_valid(acl);
+ if (ret 0)
+ goto out;
+ }
+
+ switch (type) {
+ case ACL_TYPE_ACCESS:
+ name = POSIX_ACL_XATTR_ACCESS;
+ if (acl) {
+ ret = posix_acl_equiv_mode(acl, inode-i_mode);
+ if (ret 0)
+ goto out;
+ if (ret == 0)
+ acl = NULL;
+ }
+ break;
+ case ACL_TYPE_DEFAULT:
+ if (!S_ISDIR(inode-i_mode)) {
+ ret = acl ? -EINVAL : 0;
+ goto out;
+ }
+ name = POSIX_ACL_XATTR_DEFAULT;
+ break;
+ default:
+ ret = -EINVAL;
+ goto out;
+ }
+
+
[no subject]
UK NATIONAL.pdf Description: Adobe PDF document
Re: Removing disks / OSDs
On 21/10/2013 18:49, Gregory Farnum wrote:
I'm not quite sure what questions you're actually asking here...
In general, the OSD is not removed from the system without explicit
admin intervention. When it is removed, all traces of it should be
zapped (including its key), so it can't reconnect.
If it hasn't been removed, then indeed it will continue working
properly even if moved to a different box.
If there is an external journal, the device containing the journal needs to be
moved with the device containing the data. If I read
ceph/src/upstart/ceph-osd.conf correctly, when the data device is plugged in
the new machine it will fail to start because the journal is not there yet.
When the journal device is plugged in, the ceph-osd.conf would be called
because udev rule in ceph/udev/95-ceph-osd.rules call ceph-disk
activate-journal.
Is my understanding correct ?
Cheers
-Greg
Software Engineer #42 @ http://inktank.com | http://ceph.com
On Mon, Oct 21, 2013 at 9:15 AM, Loic Dachary l...@dachary.org wrote:
Hi Ceph,
In the context of the ceph puppet module (
https://wiki.openstack.org/wiki/Puppet-openstack/ceph-blueprint ) I tried to
think about what should be provided to deal with disks / OSDs when they are
removed or moved around.
Here is a possible scenario:
* Machine A dies and contains OSD 42
* ceph osd rm 42 is done to get rid of the OSD
* ceph-prepare is called on a new disk and gets OSD id 42
ceph/src/mon/OSDMonitor.cc
// allocate a new id
for (i=0; i osdmap.get_max_osd(); i++) {
if (!osdmap.exists(i)
pending_inc.new_up_client.count(i) == 0
(pending_inc.new_state.count(i) == 0 ||
(pending_inc.new_state[i] CEPH_OSD_EXISTS) == 0))
goto done;
}
* The disk of machine A is still good and is plugged into machine C
* the udev logic sees it has the ceph magic uuid and contains a well formed
osd file system and runs the osd daemon on it. The osd daemon fails and dies
because its key does not match. It will try again and fail in the same way
when the machine reboots.
If the osd id was not reused, the disk would find its way back in the
cluster and be reused without manual intervention. Since ceph-disk uses the
osd uuid to create the disk, it does not matter that it has been removed :
https://github.com/ceph/ceph/blob/master/src/ceph-disk#L458 . I'm not sure
to understand how the key that was previously registered is re-imported. If
I understand correctly it is created with ceph-osd --mkkey
https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1301 and stored in
the osd tree at the location specified by --keyring
https://github.com/ceph/ceph/blob/master/src/ceph-disk#L1307 .
At this point my understanding is that (as long as OSD ids are not reused),
removing a disk or moving it from machine to machine, even over a long
period of time does not require any action. The OSD id is an int which is
probably large enough for any kind of cluster in the near future. The OSD
ids that are not used and not removed could be cleaned from time to time to
garbage collect the space they use.
Please let me know if I've missed something :-)
--
Loïc Dachary, Artisan Logiciel Libre
All that is necessary for the triumph of evil is that good people do nothing.
--
Loïc Dachary, Artisan Logiciel Libre
All that is necessary for the triumph of evil is that good people do nothing.
signature.asc
Description: OpenPGP digital signature
Re: xfs Warnings in syslog
Hello, So It's better to add XFS mailing list to the CC-list. :) I think this issue has been fixed by upstream commits: From ff9a28f6c25d18a635abcab1f49db68108203dfb From: Jan Kara j...@suse.cz Date: Thu, 14 Mar 2013 14:30:54 +0100 Subject: [PATCH 1/1] xfs: Fix WARN_ON(delalloc) in xfs_vm_releasepage() Thanks, -Jeff On 10/22/2013 07:46 PM, Niklas Goerke wrote: Hi My syslog and dmesg are being filled with the Warnings attached. Looking at todays syslog I got up to 1101 of these warnings in the time from 10:50 to 11:13 (and only in that time, else the log was clean). I found them on all four of my OSD hosts, all at about the same time. I'm running kernel 3.2.0-4-amd64 on a debian 7.0. Ceph is on version 0.67.4. I have got 15 OSDs per OSD Host. Ceph does not really seem to care about this, so I'm not sure what it is all about… Still they are warnings in syslog and I hope you guys can tell me what went wrong here and what I can do about it? Thank you Niklas Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388018] [ cut here ] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388030] WARNING: at /build/linux-s5x2oE/linux-3.2.46/fs/xfs/xfs_aops.c:1091 xfs_vm_releasepage+0x76/0x8e [xfs]() Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388034] Hardware name: X9DR3-F Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388036] Modules linked in: xfs autofs4 nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ext3 jbd loop acpi_cpufreq mperf coretemp crc32c_intel ghash_clmulni_intel snd_pcm aesni_intel snd_page_alloc aes_x86_64 snd_timer aes_generic s nd cryptd soundcore pcspkr sb_edac joydev evdev edac_core iTCO_wdt i2c_i801 iTCO_vendor_support i2c_core ioatdma processor thermal_sys container button ext4 crc16 jbd2 mbcache usbhid hid ses enclosure sg sd_mod crc_t10dif megaraid_sas ehci_hcd usbcore isci libsas usb_common liba ta ixgbe mdio scsi_transport_sas scsi_mod igb dca [last unloaded: scsi_wait_scan] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388093] Pid: 3459605, comm: ceph-osd Tainted: GW3.2.0-4-amd64 #1 Debian 3.2.46-1 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388096] Call Trace: Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388102] [81046b75] ? warn_slowpath_common+0x78/0x8c Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388115] [a048b98c] ? xfs_vm_releasepage+0x76/0x8e [xfs] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388122] [810bedc5] ? invalidate_inode_page+0x5e/0x80 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388129] [810bee5d] ? invalidate_mapping_pages+0x76/0x102 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388135] [810b7b83] ? sys_fadvise64_64+0x19f/0x1e2 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388140] [81353b52] ? system_call_fastpath+0x16/0x1b Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388144] ---[ end trace e9640ed6f82f066d ]--- -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xfs Warnings in syslog
Just my two cents: XFS is a quite unstable with Ceph especially along with heavy CPU usage up to 3.7(primarily soft lockups). I used 3.7 for eight months before upgrade on production system and it performs just perfectly. On Tue, Oct 22, 2013 at 1:29 PM, Jeff Liu jeff@oracle.com wrote: Hello, So It's better to add XFS mailing list to the CC-list. :) I think this issue has been fixed by upstream commits: From ff9a28f6c25d18a635abcab1f49db68108203dfb From: Jan Kara j...@suse.cz Date: Thu, 14 Mar 2013 14:30:54 +0100 Subject: [PATCH 1/1] xfs: Fix WARN_ON(delalloc) in xfs_vm_releasepage() Thanks, -Jeff On 10/22/2013 07:46 PM, Niklas Goerke wrote: Hi My syslog and dmesg are being filled with the Warnings attached. Looking at todays syslog I got up to 1101 of these warnings in the time from 10:50 to 11:13 (and only in that time, else the log was clean). I found them on all four of my OSD hosts, all at about the same time. I'm running kernel 3.2.0-4-amd64 on a debian 7.0. Ceph is on version 0.67.4. I have got 15 OSDs per OSD Host. Ceph does not really seem to care about this, so I'm not sure what it is all about… Still they are warnings in syslog and I hope you guys can tell me what went wrong here and what I can do about it? Thank you Niklas Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388018] [ cut here ] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388030] WARNING: at /build/linux-s5x2oE/linux-3.2.46/fs/xfs/xfs_aops.c:1091 xfs_vm_releasepage+0x76/0x8e [xfs]() Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388034] Hardware name: X9DR3-F Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388036] Modules linked in: xfs autofs4 nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ext3 jbd loop acpi_cpufreq mperf coretemp crc32c_intel ghash_clmulni_intel snd_pcm aesni_intel snd_page_alloc aes_x86_64 snd_timer aes_generic s nd cryptd soundcore pcspkr sb_edac joydev evdev edac_core iTCO_wdt i2c_i801 iTCO_vendor_support i2c_core ioatdma processor thermal_sys container button ext4 crc16 jbd2 mbcache usbhid hid ses enclosure sg sd_mod crc_t10dif megaraid_sas ehci_hcd usbcore isci libsas usb_common liba ta ixgbe mdio scsi_transport_sas scsi_mod igb dca [last unloaded: scsi_wait_scan] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388093] Pid: 3459605, comm: ceph-osd Tainted: GW3.2.0-4-amd64 #1 Debian 3.2.46-1 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388096] Call Trace: Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388102] [81046b75] ? warn_slowpath_common+0x78/0x8c Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388115] [a048b98c] ? xfs_vm_releasepage+0x76/0x8e [xfs] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388122] [810bedc5] ? invalidate_inode_page+0x5e/0x80 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388129] [810bee5d] ? invalidate_mapping_pages+0x76/0x102 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388135] [810b7b83] ? sys_fadvise64_64+0x19f/0x1e2 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388140] [81353b52] ? system_call_fastpath+0x16/0x1b Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388144] ---[ end trace e9640ed6f82f066d ]--- -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xfs Warnings in syslog
On 10/22/2013 08:36 PM, Andrey Korolyov wrote: Just my two cents: XFS is a quite unstable with Ceph especially along with heavy CPU usage up to 3.7(primarily soft lockups). I'm not the right person to clarify the reason as I only knew that Ceph recommend the user to deploy OSD daemon on XFS. Maybe someone can help you out if those issues have been reported to XFS list at that time. I used 3.7 for eight months before upgrade on production system and it performs just perfectly. Very glad to hear that. Thanks, -Jeff On Tue, Oct 22, 2013 at 1:29 PM, Jeff Liu jeff@oracle.com wrote: Hello, So It's better to add XFS mailing list to the CC-list. :) I think this issue has been fixed by upstream commits: From ff9a28f6c25d18a635abcab1f49db68108203dfb From: Jan Kara j...@suse.cz Date: Thu, 14 Mar 2013 14:30:54 +0100 Subject: [PATCH 1/1] xfs: Fix WARN_ON(delalloc) in xfs_vm_releasepage() Thanks, -Jeff On 10/22/2013 07:46 PM, Niklas Goerke wrote: Hi My syslog and dmesg are being filled with the Warnings attached. Looking at todays syslog I got up to 1101 of these warnings in the time from 10:50 to 11:13 (and only in that time, else the log was clean). I found them on all four of my OSD hosts, all at about the same time. I'm running kernel 3.2.0-4-amd64 on a debian 7.0. Ceph is on version 0.67.4. I have got 15 OSDs per OSD Host. Ceph does not really seem to care about this, so I'm not sure what it is all about… Still they are warnings in syslog and I hope you guys can tell me what went wrong here and what I can do about it? Thank you Niklas Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388018] [ cut here ] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388030] WARNING: at /build/linux-s5x2oE/linux-3.2.46/fs/xfs/xfs_aops.c:1091 xfs_vm_releasepage+0x76/0x8e [xfs]() Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388034] Hardware name: X9DR3-F Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388036] Modules linked in: xfs autofs4 nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ext3 jbd loop acpi_cpufreq mperf coretemp crc32c_intel ghash_clmulni_intel snd_pcm aesni_intel snd_page_alloc aes_x86_64 snd_timer aes_generic s nd cryptd soundcore pcspkr sb_edac joydev evdev edac_core iTCO_wdt i2c_i801 iTCO_vendor_support i2c_core ioatdma processor thermal_sys container button ext4 crc16 jbd2 mbcache usbhid hid ses enclosure sg sd_mod crc_t10dif megaraid_sas ehci_hcd usbcore isci libsas usb_common liba ta ixgbe mdio scsi_transport_sas scsi_mod igb dca [last unloaded: scsi_wait_scan] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388093] Pid: 3459605, comm: ceph-osd Tainted: GW3.2.0-4-amd64 #1 Debian 3.2.46-1 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388096] Call Trace: Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388102] [81046b75] ? warn_slowpath_common+0x78/0x8c Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388115] [a048b98c] ? xfs_vm_releasepage+0x76/0x8e [xfs] Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388122] [810bedc5] ? invalidate_inode_page+0x5e/0x80 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388129] [810bee5d] ? invalidate_mapping_pages+0x76/0x102 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388135] [810b7b83] ? sys_fadvise64_64+0x19f/0x1e2 Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388140] [81353b52] ? system_call_fastpath+0x16/0x1b Oct 22 11:11:19 cs-bigfoot06 kernel: [9744648.388144] ---[ end trace e9640ed6f82f066d ]--- -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Removing disks / OSDs
On Mon, Oct 21, 2013 at 11:13 PM, Loic Dachary l...@dachary.org wrote: On 21/10/2013 18:49, Gregory Farnum wrote: I'm not quite sure what questions you're actually asking here... In general, the OSD is not removed from the system without explicit admin intervention. When it is removed, all traces of it should be zapped (including its key), so it can't reconnect. If it hasn't been removed, then indeed it will continue working properly even if moved to a different box. If there is an external journal, the device containing the journal needs to be moved with the device containing the data. If I read ceph/src/upstart/ceph-osd.conf correctly, when the data device is plugged in the new machine it will fail to start because the journal is not there yet. When the journal device is plugged in, the ceph-osd.conf would be called because udev rule in ceph/udev/95-ceph-osd.rules call ceph-disk activate-journal. Is my understanding correct ? Well, after being wrong last time I'm a little reluctant to make pronouncements from memory, but that definitely sounds correct to me. :) If I were doing an audit I'd want to look at what happens if there is a wrong journal in the correct location, etc. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Removing disks / OSDs
On Tue, 22 Oct 2013, Gregory Farnum wrote: On Mon, Oct 21, 2013 at 11:13 PM, Loic Dachary l...@dachary.org wrote: On 21/10/2013 18:49, Gregory Farnum wrote: I'm not quite sure what questions you're actually asking here... In general, the OSD is not removed from the system without explicit admin intervention. When it is removed, all traces of it should be zapped (including its key), so it can't reconnect. If it hasn't been removed, then indeed it will continue working properly even if moved to a different box. If there is an external journal, the device containing the journal needs to be moved with the device containing the data. If I read ceph/src/upstart/ceph-osd.conf correctly, when the data device is plugged in the new machine it will fail to start because the journal is not there yet. When the journal device is plugged in, the ceph-osd.conf would be called because udev rule in ceph/udev/95-ceph-osd.rules call ceph-disk activate-journal. Is my understanding correct ? Well, after being wrong last time I'm a little reluctant to make pronouncements from memory, but that definitely sounds correct to me. Yep, that's how it's supposed to work. The activate-journal piece is somewhat recent though (I think maybe it wasn't in place for cuttlefish?). :) If I were doing an audit I'd want to look at what happens if there is a wrong journal in the correct location, etc. The ceph-osd will fail on start because the uuid/fsid doesn't match. sage -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ceph: add acl for cephfs
On Tue, Oct 22, 2013 at 7:50 PM, Guangliang Zhao lucienc...@gmail.com wrote:
v2: remove some redundant code in ceph_setattr()
Signed-off-by: Guangliang Zhao lucienc...@gmail.com
---
fs/ceph/Kconfig | 13 +++
fs/ceph/Makefile |1 +
fs/ceph/acl.c| 286
++
fs/ceph/dir.c|5 +
fs/ceph/inode.c | 10 ++
fs/ceph/super.c |4 +
fs/ceph/super.h | 31 ++
fs/ceph/xattr.c | 60 +---
8 files changed, 398 insertions(+), 12 deletions(-)
create mode 100644 fs/ceph/acl.c
diff --git a/fs/ceph/Kconfig b/fs/ceph/Kconfig
index ac9a2ef..264e9bf 100644
--- a/fs/ceph/Kconfig
+++ b/fs/ceph/Kconfig
@@ -25,3 +25,16 @@ config CEPH_FSCACHE
caching support for Ceph clients using FS-Cache
endif
+
+config CEPH_FS_POSIX_ACL
+ bool Ceph POSIX Access Control Lists
+ depends on CEPH_FS
+ select FS_POSIX_ACL
+ help
+ POSIX Access Control Lists (ACLs) support permissions for users and
+ groups beyond the owner/group/world scheme.
+
+ To learn more about Access Control Lists, visit the POSIX ACLs for
+ Linux website http://acl.bestbits.at/.
+
+ If you don't know what Access Control Lists are, say N
diff --git a/fs/ceph/Makefile b/fs/ceph/Makefile
index 32e3010..85a4230 100644
--- a/fs/ceph/Makefile
+++ b/fs/ceph/Makefile
@@ -10,3 +10,4 @@ ceph-y := super.o inode.o dir.o file.o locks.o addr.o
ioctl.o \
debugfs.o
ceph-$(CONFIG_CEPH_FSCACHE) += cache.o
+ceph-$(CONFIG_CEPH_FS_POSIX_ACL) += acl.o
diff --git a/fs/ceph/acl.c b/fs/ceph/acl.c
new file mode 100644
index 000..4d0c5e1
--- /dev/null
+++ b/fs/ceph/acl.c
@@ -0,0 +1,286 @@
+/*
+ * linux/fs/ceph/acl.c
+ *
+ * Copyright (C) 2013 Guangliang Zhao, lucienc...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include linux/ceph/ceph_debug.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/xattr.h
+#include linux/posix_acl_xattr.h
+#include linux/posix_acl.h
+#include linux/sched.h
+#include linux/slab.h
+
+#include super.h
+
+struct posix_acl *ceph_get_acl(struct inode *inode, int type)
+{
+ int size;
+ const char *name;
+ char *value = NULL;
+ struct posix_acl *acl;
+
+ if (!IS_POSIXACL(inode))
+ return NULL;
+
+ acl = get_cached_acl(inode, type);
+ if (acl != ACL_NOT_CACHED)
+ return acl;
+
+ switch (type) {
+ case ACL_TYPE_ACCESS:
+ name = POSIX_ACL_XATTR_ACCESS;
+ break;
+ case ACL_TYPE_DEFAULT:
+ name = POSIX_ACL_XATTR_DEFAULT;
+ break;
+ default:
+ BUG();
+ }
+
+ size = __ceph_getxattr(inode, name, , 0);
+ if (size 0) {
+ value = kzalloc(size, GFP_NOFS);
+ if (!value)
+ return ERR_PTR(-ENOMEM);
+ size = __ceph_getxattr(inode, name, value, size);
+ }
+
+ if (size 0)
+ acl = posix_acl_from_xattr(init_user_ns, value, size);
+ else if (size == -ERANGE || size == -ENODATA || size == 0)
+ acl = NULL;
+ else
+ acl = ERR_PTR(-EIO);
+
+ kfree(value);
+
+ if (!IS_ERR(acl))
+ set_cached_acl(inode, type, acl);
+
+ return acl;
+}
+
+static int ceph_set_acl(struct dentry *dentry, struct inode *inode,
+ struct posix_acl *acl, int type)
+{
+ int ret = 0, size = 0;
+ const char *name = NULL;
+ char *value = NULL;
+
+ if (acl) {
+ ret = posix_acl_valid(acl);
+ if (ret 0)
+ goto out;
+ }
+
+ switch (type) {
+ case ACL_TYPE_ACCESS:
+ name = POSIX_ACL_XATTR_ACCESS;
+ if (acl) {
+ ret = posix_acl_equiv_mode(acl, inode-i_mode);
posix_acl_equiv_mode() updates inode-i_mode. If there is
CEPH_CAP_AUTH_EXCL issued, we need to mark it dirty. Otherwise send
a request to MDS to update the i_mode.
the issue can be tested by setting ACL for a directory. (group mode
keeps unchanged after setting ACL).
Regards
Yan, Zheng
+
