Re: [B.A.T.M.A.N.] [PATCH net-next 4/5] treewide: replace dev->trans_start update with helper
On 05/03/2016 10:33 AM, Florian Westphal wrote: > Replace all trans_start updates with netif_trans_update helper. > change was done via spatch: > > struct net_device *d; > @@ > - d->trans_start = jiffies > + netif_trans_update(d) > > Compile tested only. > > Cc: user-mode-linux-de...@lists.sourceforge.net > Cc: linux-xte...@linux-xtensa.org > Cc: linux1394-de...@lists.sourceforge.net > Cc: linux-r...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: mpt-fusionlinux@broadcom.com > Cc: linux-s...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-par...@vger.kernel.org > Cc: linux-o...@vger.kernel.org > Cc: linux-h...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-wirel...@vger.kernel.org > Cc: linux-s...@vger.kernel.org > Cc: de...@driverdev.osuosl.org > Cc: b.a.t.m.a.n@lists.open-mesh.org > Cc: linux-blueto...@vger.kernel.org > Signed-off-by: Florian Westphal > --- > Checkpatch complains about whitespace damage, but > this extra whitespace already exists before this patch. > > drivers/infiniband/hw/nes/nes_nic.c| 2 +- > drivers/infiniband/ulp/ipoib/ipoib_cm.c| 2 +- > drivers/infiniband/ulp/ipoib/ipoib_ib.c| 2 +- For InfiniBand bits, Acked-by: Doug Ledford -- Doug Ledford GPG KeyID: 0E572FDD signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 2/2] fs/xattr: add *at family syscalls
On Fri, Apr 26, 2024, at 18:20, Christian Göttsche wrote:
> From: Christian Göttsche
>
> Add the four syscalls setxattrat(), getxattrat(), listxattrat() and
> removexattrat(). Those can be used to operate on extended attributes,
> especially security related ones, either relative to a pinned directory
> or on a file descriptor without read access, avoiding a
> /proc//fd/ detour, requiring a mounted procfs.
>
> One use case will be setfiles(8) setting SELinux file contexts
> ("security.selinux") without race conditions and without a file
> descriptor opened with read access requiring SELinux read permission.
>
> Use the do_{name}at() pattern from fs/open.c.
>
> Pass the value of the extended attribute, its length, and for
> setxattrat(2) the command (XATTR_CREATE or XATTR_REPLACE) via an added
> struct xattr_args to not exceed six syscall arguments and not
> merging the AT_* and XATTR_* flags.
>
> Signed-off-by: Christian Göttsche
> CC: x...@kernel.org
> CC: linux-al...@vger.kernel.org
> CC: linux-ker...@vger.kernel.org
> CC: linux-arm-ker...@lists.infradead.org
> CC: linux-i...@vger.kernel.org
> CC: linux-m...@lists.linux-m68k.org
> CC: linux-m...@vger.kernel.org
> CC: linux-par...@vger.kernel.org
> CC: linuxppc-...@lists.ozlabs.org
> CC: linux-s...@vger.kernel.org
> CC: linux...@vger.kernel.org
> CC: sparcli...@vger.kernel.org
> CC: linux-fsde...@vger.kernel.org
> CC: audit@vger.kernel.org
> CC: linux-a...@vger.kernel.org
> CC: linux-...@vger.kernel.org
> CC: linux-security-mod...@vger.kernel.org
> CC: seli...@vger.kernel.org
I checked that the syscalls are all well-formed regarding
argument types, number of arguments and (absence of)
compat handling, and that they are wired up correctly
across architectures
I did not look at the actual implementation in detail.
Reviewed-by: Arnd Bergmann
Re: [B.A.T.M.A.N.] [PATCH net-next 4/5] treewide: replace dev->trans_start update with helper
Hi, Florian Westphal writes: > Replace all trans_start updates with netif_trans_update helper. > change was done via spatch: > > struct net_device *d; > @@ > - d->trans_start = jiffies > + netif_trans_update(d) > > Compile tested only. > > Cc: user-mode-linux-de...@lists.sourceforge.net > Cc: linux-xte...@linux-xtensa.org > Cc: linux1394-de...@lists.sourceforge.net > Cc: linux-r...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: mpt-fusionlinux@broadcom.com > Cc: linux-s...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-par...@vger.kernel.org > Cc: linux-o...@vger.kernel.org > Cc: linux-h...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-wirel...@vger.kernel.org > Cc: linux-s...@vger.kernel.org > Cc: de...@driverdev.osuosl.org > Cc: b.a.t.m.a.n@lists.open-mesh.org > Cc: linux-blueto...@vger.kernel.org > Signed-off-by: Florian Westphal > --- for u_ether.c: Acked-by: Felipe Balbi > diff --git a/drivers/usb/gadget/function/u_ether.c > b/drivers/usb/gadget/function/u_ether.c > index 637809e..a3f7e7c 100644 > --- a/drivers/usb/gadget/function/u_ether.c > +++ b/drivers/usb/gadget/function/u_ether.c > @@ -597,7 +597,7 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb, > DBG(dev, "tx queue err %d\n", retval); > break; > case 0: > - net->trans_start = jiffies; > + netif_trans_update(net); > atomic_inc(&dev->tx_qlen); > } -- balbi signature.asc Description: PGP signature
Re: [B.A.T.M.A.N.] [PATCH net-next 4/5] treewide: replace dev->trans_start update with helper
On Tuesday 03 May 2016 08:03 PM, Florian Westphal wrote:
> Replace all trans_start updates with netif_trans_update helper.
> change was done via spatch:
>
> struct net_device *d;
> @@
> - d->trans_start = jiffies
> + netif_trans_update(d)
>
> Compile tested only.
>
> Cc: user-mode-linux-de...@lists.sourceforge.net
> Cc: linux-xte...@linux-xtensa.org
> Cc: linux1394-de...@lists.sourceforge.net
> Cc: linux-r...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: mpt-fusionlinux@broadcom.com
> Cc: linux-s...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-par...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-h...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-wirel...@vger.kernel.org
> Cc: linux-s...@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Cc: b.a.t.m.a.n@lists.open-mesh.org
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Florian Westphal
> ---
snip...
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 0fa75a8..3d4662d 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -1381,7 +1381,7 @@ static netdev_tx_t cpsw_ndo_start_xmit(struct sk_buff
> *skb,
> struct cpsw_priv *priv = netdev_priv(ndev);
> int ret;
>
> - ndev->trans_start = jiffies;
> + netif_trans_update(ndev);
>
> if (skb_padto(skb, CPSW_MIN_PACKET_SIZE)) {
> cpsw_err(priv, tx_err, "packet pad failed\n");
for cpsw
Acked-by: Mugunthan V N
Regards
Mugunthan V N
Re: [B.A.T.M.A.N.] [PATCH net-next 4/5] treewide: replace dev->trans_start update with helper
On Tue, May 03, 2016 at 04:33:13PM +0200, Florian Westphal wrote: > Replace all trans_start updates with netif_trans_update helper. > change was done via spatch: > > struct net_device *d; > @@ > - d->trans_start = jiffies > + netif_trans_update(d) > > Compile tested only. > > Cc: user-mode-linux-de...@lists.sourceforge.net > Cc: linux-xte...@linux-xtensa.org > Cc: linux1394-de...@lists.sourceforge.net > Cc: linux-r...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: mpt-fusionlinux@broadcom.com > Cc: linux-s...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-par...@vger.kernel.org > Cc: linux-o...@vger.kernel.org > Cc: linux-h...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-wirel...@vger.kernel.org > Cc: linux-s...@vger.kernel.org > Cc: de...@driverdev.osuosl.org > Cc: b.a.t.m.a.n@lists.open-mesh.org > Cc: linux-blueto...@vger.kernel.org > Signed-off-by: Florian Westphal > --- [...] > net/batman-adv/soft-interface.c| 2 +- [...] > diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c > index 0710379..bae1397 100644 > --- a/net/batman-adv/soft-interface.c > +++ b/net/batman-adv/soft-interface.c > @@ -208,7 +208,7 @@ static int batadv_interface_tx(struct sk_buff *skb, > if (atomic_read(&bat_priv->mesh_state) != BATADV_MESH_ACTIVE) > goto dropped; > > - soft_iface->trans_start = jiffies; > + netif_trans_update(soft_iface); > vid = batadv_get_vid(skb, 0); > ethhdr = eth_hdr(skb); > Acked-by: Antonio Quartulli -- Antonio Quartulli signature.asc Description: Digital signature
[Cluster-devel] [PATCH v13 1/5] overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh
Assumption never checked, should fail if the mounter creds are not sufficient. Signed-off-by: Mark Salyzyn Cc: Miklos Szeredi Cc: Jonathan Corbet Cc: Vivek Goyal Cc: Eric W. Biederman Cc: Amir Goldstein Cc: Randy Dunlap Cc: Stephen Smalley Cc: linux-unio...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: kernel-t...@android.com Cc: Eric Van Hensbergen Cc: Latchesar Ionkov Cc: Dominique Martinet Cc: David Howells Cc: Chris Mason Cc: Josef Bacik Cc: David Sterba Cc: Jeff Layton Cc: Sage Weil Cc: Ilya Dryomov Cc: Steve French Cc: Tyler Hicks Cc: Jan Kara Cc: Theodore Ts'o Cc: Andreas Dilger Cc: Jaegeuk Kim Cc: Chao Yu Cc: Bob Peterson Cc: Andreas Gruenbacher Cc: David Woodhouse Cc: Richard Weinberger Cc: Dave Kleikamp Cc: Greg Kroah-Hartman Cc: Tejun Heo Cc: Trond Myklebust Cc: Anna Schumaker Cc: Mark Fasheh Cc: Joel Becker Cc: Joseph Qi Cc: Mike Marshall Cc: Martin Brandenburg Cc: Alexander Viro Cc: Phillip Lougher Cc: Darrick J. Wong Cc: linux-...@vger.kernel.org Cc: Hugh Dickins Cc: David S. Miller Cc: Andrew Morton Cc: Mathieu Malaterre Cc: Ernesto A. Fernández Cc: Vyacheslav Dubeyko Cc: v9fs-develo...@lists.sourceforge.net Cc: linux-...@lists.infradead.org Cc: linux-bt...@vger.kernel.org Cc: ceph-de...@vger.kernel.org Cc: linux-c...@vger.kernel.org Cc: samba-techni...@lists.samba.org Cc: ecryp...@vger.kernel.org Cc: linux-e...@vger.kernel.org Cc: linux-f2fs-de...@lists.sourceforge.net Cc: linux-fsde...@vger.kernel.org Cc: cluster-devel@redhat.com Cc: linux-...@lists.infradead.org Cc: jfs-discuss...@lists.sourceforge.net Cc: linux-...@vger.kernel.org Cc: ocfs2-de...@oss.oracle.com Cc: de...@lists.orangefs.org Cc: reiserfs-de...@vger.kernel.org Cc: linux...@kvack.org Cc: net...@vger.kernel.org Cc: linux-security-mod...@vger.kernel.org Cc: sta...@vger.kernel.org # 4.4, 4.9, 4.14 & 4.19 --- v11 + v12 + v13 - rebase v10: - return NULL rather than ERR_PTR(-EPERM) - did _not_ add it ovl_can_decode_fh() because of changes since last review, suspect needs to be added to ovl_lower_uuid_ok()? v8 + v9: - rebase v7: - This time for realz v6: - rebase v5: - dependency of "overlayfs: override_creds=off option bypass creator_cred" --- fs/overlayfs/namei.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c index e9717c2f7d45..9702f0d5309d 100644 --- a/fs/overlayfs/namei.c +++ b/fs/overlayfs/namei.c @@ -161,6 +161,9 @@ struct dentry *ovl_decode_real_fh(struct ovl_fh *fh, struct vfsmount *mnt, if (!uuid_equal(&fh->uuid, &mnt->mnt_sb->s_uuid)) return NULL; + if (!capable(CAP_DAC_READ_SEARCH)) + return NULL; + bytes = (fh->len - offsetof(struct ovl_fh, fid)); real = exportfs_decode_fh(mnt, (struct fid *)fh->fid, bytes >> 2, (int)fh->type, -- 2.22.0.770.g0f2c4a37fd-goog
[GIT-TESTING] [PATCH] Maintainers list update: linux-net -> netdev
tree 4a3104ae491f0af76cb4a664bf72e95d084d9685 parent fcacf911953b81ab3acd6f08ec0d8bfc390bfaf1 author Horms <[EMAIL PROTECTED]> Tue Apr 12 08:26:31 2005 committer Linus Torvalds <[EMAIL PROTECTED]> Tue Apr 12 08:26:31 2005 [PATCH] Maintainers list update: linux-net -> netdev Use netdev as the mailing list contact instead of the mostly dead linux-net list. Signed-off-by: Horms <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> MAINTAINERS | 38 +++--- 1 files changed, 19 insertions(+), 19 deletions(-) Index: MAINTAINERS === --- 2a6ce87de46ff295ca920010020d8b8ae28380e1/MAINTAINERS (mode:100644 sha1:0be5aa782c6bab27d5591c56ecfe48f78233f416) +++ 4a3104ae491f0af76cb4a664bf72e95d084d9685/MAINTAINERS (mode:100644 sha1:11e253076a5ce25e040d05ac67fbba448eb8bc17) @@ -73,7 +73,7 @@ 3C359 NETWORK DRIVER P: Mike Phillips M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained @@ -81,13 +81,13 @@ 3C505 NETWORK DRIVER P: Philip Blundell M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained 3CR990 NETWORK DRIVER P: David Dillow M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained 3W- ATA-RAID CONTROLLER DRIVER @@ -143,7 +143,7 @@ 8390 NETWORK DRIVERS [WD80x3/SMC-ELITE, SMC-ULTRA, NE2000, 3C503, etc.] P: Paul Gortmaker M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained A2232 SERIAL BOARD DRIVER @@ -326,7 +326,7 @@ ARPD SUPPORT P: Jonathan Layes -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained ASUS ACPI EXTRAS DRIVER @@ -700,7 +700,7 @@ DIGI RIGHTSWITCH NETWORK DRIVER P: Rick Richardson -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com W: http://www.digi.com S: Orphaned @@ -806,7 +806,7 @@ ETHEREXPRESS-16 NETWORK DRIVER P: Philip Blundell M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained ETHERNET BRIDGE @@ -869,7 +869,7 @@ FRAME RELAY DLCI/FRAD (Sangoma drivers too) P: Mike McLagan M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained FREEVXFS FILESYSTEM @@ -1209,7 +1209,7 @@ IPX NETWORK LAYER P: Arnaldo Carvalho de Melo M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained IRDA SUBSYSTEM @@ -1586,13 +1586,13 @@ M: [EMAIL PROTECTED] P: Jeff Garzik M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained NETWORKING [GENERAL] P: Networking Team M: netdev@oss.sgi.com -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained NETWORKING [IPv4/IPv6] @@ -1628,7 +1628,7 @@ P: Jan-Pascal van Best and Andreas Mohr M: Jan-Pascal van Best <[EMAIL PROTECTED]> M: Andreas Mohr <[EMAIL PROTECTED]> -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained NINJA SCSI-3 / NINJA SCSI-32Bi (16bit/CardBus) PCMCIA SCSI HOST ADAPTER DRIVER @@ -1670,7 +1670,7 @@ M: [EMAIL PROTECTED] P: Mike Phillips M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained @@ -1775,7 +1775,7 @@ PCNET32 NETWORK DRIVER P: Thomas Bogendörfer M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained PHRAM MTD DRIVER @@ -1787,7 +1787,7 @@ POSIX CLOCKS and TIMERS P: George Anzinger M: george@mvista.com -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Supported PNP SUPPORT @@ -2039,7 +2039,7 @@ P: Daniele Venzano M: [EMAIL PROTECTED] W: http://www.brownhat.org/sis900.html -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained SIS FRAMEBUFFER DRIVER @@ -2098,7 +2098,7 @@ SONIC NETWORK DRIVER P: Thomas Bogendoerfer M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Maintained SONY VAIO CONTROL DEVICE DRIVER @@ -2148,7 +2148,7 @@ SPX NETWORK LAYER P: Jay Schulist M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com S: Supported SRM (Alpha) environment access @@ -2227,7 +2227,7 @@ TOKEN-RING NETWORK DRIVER P: Mike Phillips M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: netdev@oss.sgi.com L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained - To unsubscribe from this list: send
[PATCH] Maintainers list update: linux-net -> netdev
tree a21b3ea586b7754f632d9c9e088e6dbc9932e6df parent 5960f3a63394c091b17682aed3bd8fdd994a1b93 author Horms <[EMAIL PROTECTED]> Sun, 17 Apr 2005 05:26:03 -0700 committer Linus Torvalds <[EMAIL PROTECTED]> Sun, 17 Apr 2005 05:26:03 -0700 [PATCH] Maintainers list update: linux-net -> netdev Use netdev as the mailing list contact instead of the mostly dead linux-net list. Signed-off-by: Horms <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> MAINTAINERS | 38 +++--- 1 files changed, 19 insertions(+), 19 deletions(-) Index: MAINTAINERS === --- 144eb8a1622ef682071f5eb3449d9b1f042a296d/MAINTAINERS (mode:100644 sha1:55fe0b855e6b89812439ea0974b969299e5deb5f) +++ a21b3ea586b7754f632d9c9e088e6dbc9932e6df/MAINTAINERS (mode:100644 sha1:8e8b492945ad7bfc88275ef421fec2f5696f5329) @@ -73,7 +73,7 @@ 3C359 NETWORK DRIVER P: Mike Phillips M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained @@ -81,13 +81,13 @@ 3C505 NETWORK DRIVER P: Philip Blundell M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained 3CR990 NETWORK DRIVER P: David Dillow M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained 3W- ATA-RAID CONTROLLER DRIVER @@ -143,7 +143,7 @@ 8390 NETWORK DRIVERS [WD80x3/SMC-ELITE, SMC-ULTRA, NE2000, 3C503, etc.] P: Paul Gortmaker M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained A2232 SERIAL BOARD DRIVER @@ -326,7 +326,7 @@ ARPD SUPPORT P: Jonathan Layes -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained ASUS ACPI EXTRAS DRIVER @@ -700,7 +700,7 @@ DIGI RIGHTSWITCH NETWORK DRIVER P: Rick Richardson -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] W: http://www.digi.com S: Orphaned @@ -806,7 +806,7 @@ ETHEREXPRESS-16 NETWORK DRIVER P: Philip Blundell M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained ETHERNET BRIDGE @@ -869,7 +869,7 @@ FRAME RELAY DLCI/FRAD (Sangoma drivers too) P: Mike McLagan M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained FREEVXFS FILESYSTEM @@ -1209,7 +1209,7 @@ IPX NETWORK LAYER P: Arnaldo Carvalho de Melo M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained IRDA SUBSYSTEM @@ -1586,13 +1586,13 @@ M: [EMAIL PROTECTED] P: Jeff Garzik M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained NETWORKING [GENERAL] P: Networking Team M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained NETWORKING [IPv4/IPv6] @@ -1628,7 +1628,7 @@ P: Jan-Pascal van Best and Andreas Mohr M: Jan-Pascal van Best <[EMAIL PROTECTED]> M: Andreas Mohr <[EMAIL PROTECTED]> -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained NINJA SCSI-3 / NINJA SCSI-32Bi (16bit/CardBus) PCMCIA SCSI HOST ADAPTER DRIVER @@ -1670,7 +1670,7 @@ M: [EMAIL PROTECTED] P: Mike Phillips M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained @@ -1775,7 +1775,7 @@ PCNET32 NETWORK DRIVER P: Thomas Bogendörfer M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained PHRAM MTD DRIVER @@ -1787,7 +1787,7 @@ POSIX CLOCKS and TIMERS P: George Anzinger M: george@mvista.com -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Supported PNP SUPPORT @@ -2039,7 +2039,7 @@ P: Daniele Venzano M: [EMAIL PROTECTED] W: http://www.brownhat.org/sis900.html -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained SIS FRAMEBUFFER DRIVER @@ -2098,7 +2098,7 @@ SONIC NETWORK DRIVER P: Thomas Bogendoerfer M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Maintained SONY VAIO CONTROL DEVICE DRIVER @@ -2148,7 +2148,7 @@ SPX NETWORK LAYER P: Jay Schulist M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] S: Supported SRM (Alpha) environment access @@ -2227,7 +2227,7 @@ TOKEN-RING NETWORK DRIVER P: Mike Phillips M: [EMAIL PROTECTED] -L: linux-net@vger.kernel.org +L: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained - To unsubscribe from this list: send the line
Re: [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize new kmap_thread()
-ira.we...@intel.com wrote: -
>To: "Andrew Morton" , "Thomas Gleixner"
>, "Ingo Molnar" , "Borislav
>Petkov" , "Andy Lutomirski" , "Peter
>Zijlstra"
>From: ira.we...@intel.com
>Date: 10/09/2020 09:52PM
>Cc: "Ira Weiny" , "Mike Marciniszyn"
>, "Dennis Dalessandro"
>, "Doug Ledford" ,
>"Jason Gunthorpe" , "Faisal Latif"
>, "Shiraz Saleem" ,
>"Bernard Metzler" , x...@kernel.org, "Dave Hansen"
>, "Dan Williams"
>, "Fenghua Yu" ,
>linux-...@vger.kernel.org, linux-ker...@vger.kernel.org,
>linux-nvd...@lists.01.org, linux-fsde...@vger.kernel.org,
>linux...@kvack.org, linux-kselft...@vger.kernel.org,
>linuxppc-...@lists.ozlabs.org, k...@vger.kernel.org,
>net...@vger.kernel.org, b...@vger.kernel.org,
>ke...@lists.infradead.org, linux-bca...@vger.kernel.org,
>linux-...@lists.infradead.org, de...@driverdev.osuosl.org,
>linux-...@vger.kernel.org, linux-...@vger.kernel.org,
>linux-s...@vger.kernel.org, target-de...@vger.kernel.org,
>linux-...@vger.kernel.org, ceph-de...@vger.kernel.org,
>linux-e...@vger.kernel.org, linux-...@kvack.org,
>io-ur...@vger.kernel.org, linux-er...@lists.ozlabs.org,
>linux...@lists.infradead.org, linux-ntfs-...@lists.sourceforge.net,
>reiserfs-de...@vger.kernel.org,
>linux-f2fs-de...@lists.sourceforge.net, linux-ni...@vger.kernel.org,
>cluster-de...@redhat.com, ecryp...@vger.kernel.org,
>linux-c...@vger.kernel.org, linux-bt...@vger.kernel.org,
>linux-...@lists.infradead.org, linux-r...@vger.kernel.org,
>amd-gfx@lists.freedesktop.org, dri-de...@lists.freedesktop.org,
>intel-...@lists.freedesktop.org, drbd-...@tron.linbit.com,
>linux-bl...@vger.kernel.org, xen-de...@lists.xenproject.org,
>linux-cach...@redhat.com, samba-techni...@lists.samba.org,
>intel-wired-...@lists.osuosl.org
>Subject: [EXTERNAL] [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize
>new kmap_thread()
>
>From: Ira Weiny
>
>The kmap() calls in these drivers are localized to a single thread.
>To
>avoid the over head of global PKRS updates use the new kmap_thread()
>call.
>
>Cc: Mike Marciniszyn
>Cc: Dennis Dalessandro
>Cc: Doug Ledford
>Cc: Jason Gunthorpe
>Cc: Faisal Latif
>Cc: Shiraz Saleem
>Cc: Bernard Metzler
>Signed-off-by: Ira Weiny
>---
> drivers/infiniband/hw/hfi1/sdma.c | 4 ++--
> drivers/infiniband/hw/i40iw/i40iw_cm.c | 10 +-
> drivers/infiniband/sw/siw/siw_qp_tx.c | 14 +++---
> 3 files changed, 14 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/infiniband/hw/hfi1/sdma.c
>b/drivers/infiniband/hw/hfi1/sdma.c
>index 04575c9afd61..09d206e3229a 100644
>--- a/drivers/infiniband/hw/hfi1/sdma.c
>+++ b/drivers/infiniband/hw/hfi1/sdma.c
>@@ -3130,7 +3130,7 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata
>*dd, struct sdma_txreq *tx,
> }
>
> if (type == SDMA_MAP_PAGE) {
>- kvaddr = kmap(page);
>+ kvaddr = kmap_thread(page);
> kvaddr += offset;
> } else if (WARN_ON(!kvaddr)) {
> __sdma_txclean(dd, tx);
>@@ -3140,7 +3140,7 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata
>*dd, struct sdma_txreq *tx,
> memcpy(tx->coalesce_buf + tx->coalesce_idx, kvaddr, len);
> tx->coalesce_idx += len;
> if (type == SDMA_MAP_PAGE)
>- kunmap(page);
>+ kunmap_thread(page);
>
> /* If there is more data, return */
> if (tx->tlen - tx->coalesce_idx)
>diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c
>b/drivers/infiniband/hw/i40iw/i40iw_cm.c
>index a3b95805c154..122d7a5642a1 100644
>--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
>+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
>@@ -3721,7 +3721,7 @@ int i40iw_accept(struct iw_cm_id *cm_id, struct
>iw_cm_conn_param *conn_param)
> ibmr->device = iwpd->ibpd.device;
> iwqp->lsmm_mr = ibmr;
> if (iwqp->page)
>- iwqp->sc_qp.qp_uk.sq_base = kmap(iwqp->page);
>+ iwqp->sc_qp.qp_uk.sq_base = kmap_thread(iwqp->page);
> dev->iw_priv_qp_ops->qp_send_lsmm(&iwqp->sc_qp,
> iwqp->ietf_mem.va,
> (accept.size +
> conn_param->private_data_len),
>@@ -3729,12 +3729,12 @@ int i40iw_accept(struct iw_cm_id *cm_id,
>struct iw_cm_conn_param *conn_param)
>
> } else {
> if (iwqp
Re: [Cluster-devel] [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize new kmap_thread()
-ira.we...@intel.com wrote: -
>To: "Andrew Morton" , "Thomas Gleixner"
>, "Ingo Molnar" , "Borislav
>Petkov" , "Andy Lutomirski" , "Peter
>Zijlstra"
>From: ira.we...@intel.com
>Date: 10/09/2020 09:52PM
>Cc: "Ira Weiny" , "Mike Marciniszyn"
>, "Dennis Dalessandro"
>, "Doug Ledford" ,
>"Jason Gunthorpe" , "Faisal Latif"
>, "Shiraz Saleem" ,
>"Bernard Metzler" , x...@kernel.org, "Dave Hansen"
>, "Dan Williams"
>, "Fenghua Yu" ,
>linux-...@vger.kernel.org, linux-ker...@vger.kernel.org,
>linux-nvd...@lists.01.org, linux-fsde...@vger.kernel.org,
>linux...@kvack.org, linux-kselft...@vger.kernel.org,
>linuxppc-...@lists.ozlabs.org, k...@vger.kernel.org,
>net...@vger.kernel.org, b...@vger.kernel.org,
>ke...@lists.infradead.org, linux-bca...@vger.kernel.org,
>linux-...@lists.infradead.org, de...@driverdev.osuosl.org,
>linux-...@vger.kernel.org, linux-...@vger.kernel.org,
>linux-s...@vger.kernel.org, target-de...@vger.kernel.org,
>linux-...@vger.kernel.org, ceph-de...@vger.kernel.org,
>linux-e...@vger.kernel.org, linux-...@kvack.org,
>io-ur...@vger.kernel.org, linux-er...@lists.ozlabs.org,
>linux...@lists.infradead.org, linux-ntfs-...@lists.sourceforge.net,
>reiserfs-de...@vger.kernel.org,
>linux-f2fs-de...@lists.sourceforge.net, linux-ni...@vger.kernel.org,
>cluster-devel@redhat.com, ecryp...@vger.kernel.org,
>linux-c...@vger.kernel.org, linux-bt...@vger.kernel.org,
>linux-...@lists.infradead.org, linux-r...@vger.kernel.org,
>amd-...@lists.freedesktop.org, dri-de...@lists.freedesktop.org,
>intel-...@lists.freedesktop.org, drbd-...@tron.linbit.com,
>linux-bl...@vger.kernel.org, xen-de...@lists.xenproject.org,
>linux-cach...@redhat.com, samba-techni...@lists.samba.org,
>intel-wired-...@lists.osuosl.org
>Subject: [EXTERNAL] [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize
>new kmap_thread()
>
>From: Ira Weiny
>
>The kmap() calls in these drivers are localized to a single thread.
>To
>avoid the over head of global PKRS updates use the new kmap_thread()
>call.
>
>Cc: Mike Marciniszyn
>Cc: Dennis Dalessandro
>Cc: Doug Ledford
>Cc: Jason Gunthorpe
>Cc: Faisal Latif
>Cc: Shiraz Saleem
>Cc: Bernard Metzler
>Signed-off-by: Ira Weiny
>---
> drivers/infiniband/hw/hfi1/sdma.c | 4 ++--
> drivers/infiniband/hw/i40iw/i40iw_cm.c | 10 +-
> drivers/infiniband/sw/siw/siw_qp_tx.c | 14 +++---
> 3 files changed, 14 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/infiniband/hw/hfi1/sdma.c
>b/drivers/infiniband/hw/hfi1/sdma.c
>index 04575c9afd61..09d206e3229a 100644
>--- a/drivers/infiniband/hw/hfi1/sdma.c
>+++ b/drivers/infiniband/hw/hfi1/sdma.c
>@@ -3130,7 +3130,7 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata
>*dd, struct sdma_txreq *tx,
> }
>
> if (type == SDMA_MAP_PAGE) {
>- kvaddr = kmap(page);
>+ kvaddr = kmap_thread(page);
> kvaddr += offset;
> } else if (WARN_ON(!kvaddr)) {
> __sdma_txclean(dd, tx);
>@@ -3140,7 +3140,7 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata
>*dd, struct sdma_txreq *tx,
> memcpy(tx->coalesce_buf + tx->coalesce_idx, kvaddr, len);
> tx->coalesce_idx += len;
> if (type == SDMA_MAP_PAGE)
>- kunmap(page);
>+ kunmap_thread(page);
>
> /* If there is more data, return */
> if (tx->tlen - tx->coalesce_idx)
>diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c
>b/drivers/infiniband/hw/i40iw/i40iw_cm.c
>index a3b95805c154..122d7a5642a1 100644
>--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
>+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
>@@ -3721,7 +3721,7 @@ int i40iw_accept(struct iw_cm_id *cm_id, struct
>iw_cm_conn_param *conn_param)
> ibmr->device = iwpd->ibpd.device;
> iwqp->lsmm_mr = ibmr;
> if (iwqp->page)
>- iwqp->sc_qp.qp_uk.sq_base = kmap(iwqp->page);
>+ iwqp->sc_qp.qp_uk.sq_base = kmap_thread(iwqp->page);
> dev->iw_priv_qp_ops->qp_send_lsmm(&iwqp->sc_qp,
> iwqp->ietf_mem.va,
> (accept.size +
> conn_param->private_data_len),
>@@ -3729,12 +3729,12 @@ int i40iw_accept(struct iw_cm_id *cm_id,
>struct iw_cm_conn_param *conn_param)
>
> } else {
> if (iwqp
RE: [PATCH 10/28] drm: amdgpu: Use PCI_IRQ_INTX
[Public] > -Original Message- > From: amd-gfx On Behalf Of > Damien Le Moal > Sent: Monday, March 25, 2024 3:09 AM > To: linux-...@vger.kernel.org; Bjorn Helgaas ; > Manivannan Sadhasivami ; linux- > s...@vger.kernel.org; Martin K . Petersen ; > Jaroslav Kysela ; linux-so...@vger.kernel.org; Greg Kroah- > Hartman ; linux-...@vger.kernel.org; linux- > ser...@vger.kernel.org; Hans de Goede ; platform- > driver-...@vger.kernel.org; n...@lists.linux.dev; Lee Jones ; > David Airlie ; amd-gfx@lists.freedesktop.org; Jason > Gunthorpe ; linux-r...@vger.kernel.org; David S . Miller > ; Eric Dumazet ; > net...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: [PATCH 10/28] drm: amdgpu: Use PCI_IRQ_INTX > > Use the macro PCI_IRQ_INTX instead of the deprecated PCI_IRQ_LEGACY > macro. > > Signed-off-by: Damien Le Moal Feel free to take it through whatever tree makes sense. If you want me to pick it up, let me know. Acked-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c > index 7e6d09730e6d..d18113017ee7 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c > @@ -279,7 +279,7 @@ int amdgpu_irq_init(struct amdgpu_device *adev) > adev->irq.msi_enabled = false; > > if (!amdgpu_msi_ok(adev)) > - flags = PCI_IRQ_LEGACY; > + flags = PCI_IRQ_INTX; > else > flags = PCI_IRQ_ALL_TYPES; > > -- > 2.44.0
[PATCH v3 00/26] compat_ioctl: cleanups
re/devio.c| 16 +- drivers/usb/gadget/function/f_fs.c | 12 +- drivers/vfio/vfio.c | 39 +- drivers/vhost/net.c | 12 +- drivers/vhost/scsi.c| 12 +- drivers/vhost/test.c| 12 +- drivers/vhost/vsock.c | 12 +- drivers/video/fbdev/aty/atyfb_base.c| 12 +- drivers/virt/fsl_hypervisor.c | 2 +- fs/btrfs/super.c| 2 +- fs/ceph/dir.c | 1 + fs/ceph/file.c | 2 +- fs/compat_ioctl.c | 602 +--- fs/fat/file.c | 13 +- fs/fuse/dev.c | 2 +- fs/notify/fanotify/fanotify_user.c | 2 +- fs/userfaultfd.c| 2 +- include/linux/fs.h | 7 + include/linux/if_pppox.h| 2 + include/linux/mtio.h| 58 ++ include/uapi/linux/ppp-ioctl.h | 2 + include/uapi/linux/ppp_defs.h | 14 + net/bluetooth/hci_sock.c| 21 +- net/bluetooth/rfcomm/sock.c | 14 +- net/l2tp/l2tp_ppp.c | 3 + net/rfkill/core.c | 2 +- sound/core/oss/pcm_oss.c| 4 + sound/oss/dmasound/dmasound_core.c | 2 + 82 files changed, 452 insertions(+), 1034 deletions(-) create mode 100644 include/linux/mtio.h -- 2.20.0 Cc: "David S. Miller" Cc: Greg Kroah-Hartman Cc: Karsten Keil Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: Marcel Holtmann Cc: net...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: linux-integr...@vger.kernel.org Cc: qat-li...@intel.com Cc: linux-cry...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linux1394-de...@lists.sourceforge.net Cc: amd-gfx@lists.freedesktop.org Cc: linux-in...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-r...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: linux-n...@lists.infradead.org Cc: platform-driver-...@vger.kernel.org Cc: linux-remotep...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: linux-fb...@vger.kernel.org Cc: linux-bt...@vger.kernel.org Cc: ceph-de...@vger.kernel.org Cc: linux-fsde...@vger.kernel.org Cc: linux-blueto...@vger.kernel.org Cc: linux-wirel...@vger.kernel.org Cc: alsa-de...@alsa-project.org Cc: y2...@lists.linaro.org ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 00/17] spelling.txt: /decriptors/descriptors/
On Tue, Jun 09, 2020 at 01:45:53PM +0100, Kieran Bingham wrote: > I wouldn't normally go through spelling fixes, but I caught sight of > this typo twice, and then foolishly grepped the tree for it, and saw how > pervasive it was. > > so here I am ... fixing a typo globally... but with an addition in > scripts/spelling.txt so it shouldn't re-appear ;-) > > Cc: linux-arm-ker...@lists.infradead.org (moderated list:TI DAVINCI MACHINE > SUPPORT) > Cc: linux-ker...@vger.kernel.org (open list) > Cc: linux...@vger.kernel.org (open list:DEVICE FREQUENCY EVENT > (DEVFREQ-EVENT)) > Cc: linux-g...@vger.kernel.org (open list:GPIO SUBSYSTEM) > Cc: dri-de...@lists.freedesktop.org (open list:DRM DRIVERS) > Cc: linux-r...@vger.kernel.org (open list:HFI1 DRIVER) > Cc: linux-in...@vger.kernel.org (open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, > TOUCHSCREEN)...) > Cc: linux-...@lists.infradead.org (open list:NAND FLASH SUBSYSTEM) > Cc: net...@vger.kernel.org (open list:NETWORKING DRIVERS) > Cc: ath10k@lists.infradead.org (open list:QUALCOMM ATHEROS ATH10K WIRELESS > DRIVER) > Cc: linux-wirel...@vger.kernel.org (open list:NETWORKING DRIVERS (WIRELESS)) > Cc: linux-s...@vger.kernel.org (open list:IBM Power Virtual FC Device Drivers) > Cc: linuxppc-...@lists.ozlabs.org (open list:LINUX FOR POWERPC (32-BIT AND > 64-BIT)) > Cc: linux-...@vger.kernel.org (open list:USB SUBSYSTEM) > Cc: virtualizat...@lists.linux-foundation.org (open list:VIRTIO CORE AND NET > DRIVERS) > Cc: linux...@kvack.org (open list:MEMORY MANAGEMENT) > > > Kieran Bingham (17): > arch: arm: mach-davinci: Fix trivial spelling > drivers: infiniband: Fix trivial spelling > drivers: infiniband: Fix trivial spelling I took these two RDMA patches and merged them, thanks Jason ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Moving away from Yum/DNF repo priorities for Ceph and ceph-deploy
Haha, yes. I still use yum for everything. :D Mark On 07/24/2015 08:18 PM, Shinobu Kinjo wrote: If there's really no better way around this, I think we need to communicate to the Yum/DMF team(s) what the problem is and that we need to come up with some better way to control the priorities. Given that DMF is fairly new, it seems like a prime time to work with them no? I agree. But remember not DMF but DNF -; - Shinobu - Travis [1] http://wiki.centos.org/PackageManagement/Yum/Priorities#head-38b91468cc607d0243f463489c2334bf40bfaaee [2] http://wiki.centos.org/PackageManagement/Yum/Priorities#head-6601a4937d4b099e6d46eea0bdb54241d51c7277-- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org <mailto: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 <mailto:majord...@vger.kernel.org> More majordomo info at http://vger.kernel.org/majordomo-info.html -- Email: shin...@linux.com <mailto:shin...@linux.com> ski...@redhat.com <mailto:ski...@redhat.com> Life w/ Linux <http://i-shinobu.hatenablog.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: are there plans to move to a newer google perftools?
We repackaged dumpling using libgoogle-perftools4 and it does work, and does cohabitate with mongo. > -Original Message- > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > ow...@vger.kernel.org] On Behalf Of Don Talton (dotalton) > Sent: Monday, December 09, 2013 6:53 PM > To: Sage Weil > Cc: Ceph Development (ceph-devel@vger.kernel.org) > Subject: RE: are there plans to move to a newer google perftools? > > I should add, I am using ceph deploy. Here is the output: > > > 2013-12-09 18:42:58,340 [ceph][DEBUG ] The following packages have unmet > dependencies: > 2013-12-09 18:42:58,340 [ceph][DEBUG ] ceph : Depends: libgoogle- > perftools0 but it is not going to be installed > 2013-12-09 18:42:58,340 [ceph][DEBUG ] ceph-mds : Depends: libgoogle- > perftools0 but it is not going to be installed > 2013-12-09 18:42:58,341 [ceph][ERROR ] RuntimeError: command returned > non-zero exit status: 100 > 2013-12-09 18:42:58,341 [ceph_deploy][ERROR ] RuntimeError: Failed to > execute command: env DEBIAN_FRONTEND=noninteractive > DEBIAN_PRIORITY=critical apt-get -q -o Dpkg::Options::=--force-confnew -- > no-install-recommends --assume-yes install -- ceph ceph-mds ceph-common > ceph-fs-common gdisk > > > > > > > > > -Original Message- > > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > > ow...@vger.kernel.org] On Behalf Of Don Talton (dotalton) > > Sent: Monday, December 09, 2013 6:47 PM > > To: Sage Weil > > Cc: Ceph Development (ceph-devel@vger.kernel.org) > > Subject: RE: are there plans to move to a newer google perftools? > > > > Hi Sage, > > > > It's Ubuntu 12.04 LTS > > > > Mongo wants to install libgoogle-perftools4, whereas ceph wants to > > install libgoogle-perftools0. > > > > This is leaving libgoogle-perftools0 in a broken state and, I'm > > assuming this is the cause, making ceph fault. Ceph works great before > > the installation of libgoogle-perftools4. > > > > This is with using mongo v2.4.6 and seemingly any version of ceph. > > I've tried bobtail, dumpling, and cuttlefish. > > > > Dpkg status: > > rc libgoogle-perftools0 > > ii libgoogle-perftools4 > > > > dpkg -p ceph: > > Depends: binutils, ceph-common, cryptsetup-bin | cryptsetup, gdisk, > > parted, python, python-argparse, sdparm | hdparm, uuid-runtime, > > xfsprogs, libaio1 (>= 0.3.93), libboost-thread1.46.1 (>= 1.46.1-1), > > libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libgoogle-perftools0, libnspr4 > > (>= 1.8.0.10), libnss3 (>= 3.12.0~1.9b1), libsnappy1, libstdc++6 (>= > > 4.6), libuuid1 (>= 2.16) > > > > It makes sense that ceph would use the latest, but it's exploding for > > me :) > > > > > > > -Original Message- > > > From: Sage Weil [mailto:s...@inktank.com] > > > Sent: Monday, December 09, 2013 6:07 PM > > > To: Don Talton (dotalton) > > > Cc: Ceph Development (ceph-devel@vger.kernel.org) > > > Subject: Re: are there plans to move to a newer google perftools? > > > > > > Hi Donald, > > > > > > What exactly is the conflict? And what distro? I believe we should > > > be using whatever version of the library is installed. > > > > > > sage > > > > > > On Tue, 10 Dec 2013, Don Talton (dotalton) wrote: > > > > > > > I'm trying to package/install mongodb and ceph on the same server > > > > and > > > there are conflict due to the version differences. > > > > > > > > Donald Talton > > > > Systems Development Unit > > > > dotal...@cisco.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 > > > > > > > > > > -- > > 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: Cache tiering slow request issue: currently waiting for rw locks
can we set the cache_min_evict_age to a reasonable larger number (say 5min? 10min?) to walk around the window?-If a request cannot finished in minutes, that indicate there should be some issue in the cluster. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Wang, Zhiqiang Sent: Tuesday, September 9, 2014 3:13 PM To: Sage Weil; 'sam.j...@inktank.com' Cc: 'ceph-devel@vger.kernel.org' Subject: RE: Cache tiering slow request issue: currently waiting for rw locks Pasting the conversations in the pull request here. wonzhq commented 6 days ago If checking ObjectContext::RWState::waiters and ObjectContext::RWState::count for the pending requests on this object, there is still a window which the problem can happen. That is after the promotion replication and requeuing the client request, and before dequeuing the client request. Should we loop the OSD::op_wq to check the pending requests on an object? Or adding something in the ObjectContext to remember the pending requests? @athanatos @liewegas liewegas commented 10 hours ago Hmm, that's true that there is still that window. Is it necessary that this is completely air-tight, though? As long as we avoid evicting a newly-promoted object before the request is processed we will win. I'm afraid that a complicated mechanism to cover this could introduce more complexity than we need. wonzhq commented 2 minutes ago Tried to use ObjectContext::RWState::count to check the pending request. In my testing, it hit the slow request just once. I checked the log, it exactly falls into the window we talked above. So with this solution, it's possible that we still hit this issue, but much less than before. Should we go ahead with this solution? Sage/Sam, what do you think? -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Wang, Zhiqiang Sent: Friday, September 5, 2014 3:21 PM To: Sage Weil; 'sam.j...@inktank.com' Cc: 'ceph-devel@vger.kernel.org' Subject: RE: Cache tiering slow request issue: currently waiting for rw locks I made some comments based on your comments of the pull request https://github.com/ceph/ceph/pull/2374. Can you take a look? Thx. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Wang, Zhiqiang Sent: Tuesday, September 2, 2014 2:54 PM To: Sage Weil Cc: 'ceph-devel@vger.kernel.org' Subject: RE: Cache tiering slow request issue: currently waiting for rw locks Tried the pull request, checking the object is blocked or not doesn't work. Actually this check is already done in function agent_work. I tried to make a fix to add a field/flag to the object context. This is not a good idea for the following reasons: 1) If making this filed/flag to be a persistent one, when resetting/clearing this flag, we need to persist it. This is not good for read request. 2) If making this field/flag not to be a persistent one, when the object context is removed from the cache ' object_contexts', this field/flag is removed as well. This object is removed in the later evicting. The same issue still exists. So, I came up with a fix to add a set in the class ReplicatedPG to hold all the promoting objects. This fix is at https://github.com/ceph/ceph/pull/2374. It is tested and works well. Pls review and comment, thx. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Wang, Zhiqiang Sent: Monday, September 1, 2014 9:33 AM To: Sage Weil Cc: 'ceph-devel@vger.kernel.org' Subject: RE: Cache tiering slow request issue: currently waiting for rw locks I don't think the object context is blocked at that time. It is un-blocked after the copying of data from base tier. It doesn't address the problem here. Anyway, I'll try it and see. -----Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil Sent: Saturday, August 30, 2014 10:29 AM To: Wang, Zhiqiang Cc: 'ceph-devel@vger.kernel.org' Subject: Re: Cache tiering slow request issue: currently waiting for rw locks Hi, Can you take a look at https://github.com/ceph/ceph/pull/2363 and see if that addresses the behavior you saw? Thanks! sage On Fri, 29 Aug 2014, Sage Weil wrote: > Hi, > > I've opened http://tracker.ceph.com/issues/9285 to track this. > > I think you're right--we need a check in agent_maybe_evict() that will > skip objects that are being promoted. I suspect a flag on the > ObjectContext is enough? > > sage > > > On Fri, 29 Aug 2014, Wang, Zhiqiang wrote: > > > Hi all, > > > > I've ran into this slow request issue some time ago. The problem is l
RE: building just src/tools/rados
Hi Tom, Have you tried cd src; make rados? Regards, Igor. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Deneau, Tom Sent: Wednesday, July 22, 2015 10:13 PM To: ceph-devel Subject: building just src/tools/rados Is there a make command that would build just the src/tools or even just src/tools/rados ? -- Tom Deneau -- 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: Recovery stuck and radosgateway not initializing
We had a bunch of disk who failed. That's why ceph was having trouble keeping OSD up. And we found that during recovery the rados gateway failed to initialize. The init_watch function timeout. As it is only used when cache is activated, we disable cache (rgw cache enable false) and the radosgateway started :) ! -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Yann ROBIN Sent: mardi 18 décembre 2012 15:08 To: ceph-devel@vger.kernel.org Subject: RE: Recovery stuck and radosgateway not initializing Our configuration : 6 OSDs, 3 Mon. Journal is on INTEL SSDSA2CW120G3 disk and Data is on Hitachi HUS724040ALE640 disk. When OSD does recovery IO is high, and at some point the OSD is killed. We set max active recovery to 1 and set filestore op thread suicide timeout to 360. What should I do in that case ? -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Yann ROBIN Sent: mardi 18 décembre 2012 11:51 To: ceph-devel@vger.kernel.org Subject: Recovery stuck and radosgateway not initializing Hi, We're using ceph v0.55, and last night we loste one node of our cluster. When it came back, ceph start recovering but since then the radosgateway could not connect to the cluster. The rados gateway timeout on initializtion (somewhere in the radosclient connect). The other problem (and I think it's related) is that the recovery isn't working. Osd gets OSD Op thread timeout and sometimes some of the OSD crash (see stacktrace attached). So it seems that our OSD aren't up long enough for the recovery to proceed. Any would be appreciated. Thanks, -- Yann -- 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:
Wrong email address -- send it to majord...@vger.kernel.org! :) On Sun, Apr 4, 2010 at 6:04 PM, haiyang kang wrote: > subscribe ceph-devel > -- > 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: deleting objects from a pool
Hi, It appears, that cleanup can be used as a purge: rados -p cleanup --prefix "" Regards, Igor. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Deneau, Tom Sent: Wednesday, June 24, 2015 10:22 PM To: Dałek, Piotr; ceph-devel Subject: RE: deleting objects from a pool I've noticed that deleting objects from a basic k=2 m=1 erasure pool is much much slower than deleting a similar number of objects from a replicated size 3 pool (so the same number of files to be deleted). It looked like the ec pool object deletion was almost 20x slower. Is there a lot more work to be done to delete an ec pool object? -- Tom > -Original Message- > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > ow...@vger.kernel.org] On Behalf Of Dalek, Piotr > Sent: Wednesday, June 24, 2015 11:56 AM > To: ceph-devel > Subject: Re: deleting objects from a pool > > > -Original Message- > > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > > ow...@vger.kernel.org] On Behalf Of Deneau, Tom > > Sent: Wednesday, June 24, 2015 6:44 PM > > > > I have benchmarking situations where I want to leave a pool around > > but delete a lot of objects from the pool. Is there any really fast > > way to do > that? > > I noticed rados rmpool is fast but I don't want to remove the pool. > > > > I have been spawning multiple threads, each deleting a subset of the > objects > > (which I believe is what rados bench write does) but even that can > > be very slow. > > For now, apart from "rados -p cleanup" (which doesn't purge > the pool, but merely removes objects written during last benchmark > run), the only option is by brute force: > > for i in $(rados -p ls); do (rados -p rm $i > &>/dev/null &); done; > > There's no "purge pool" command in rados -- not yet, at least. I was > thinking about one, but never really had time to implement one. > > With best regards / Pozdrawiam > Piotr Dałek > -- > 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: deleting objects from a pool
If you have rados bench data around, you'll need to run cleanup a second time because the first time the "benchmark_last_metadata" object will be consulted to find what objects to remove. Also, using cleanup this way will only remove objects from the default namespace unless a namespace is specified with the -N option. rados -p -N cleanup --prefix "" David On 6/24/15 11:06 PM, Podoski, Igor wrote: Hi, It appears, that cleanup can be used as a purge: rados -p cleanup --prefix "" Regards, Igor. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Deneau, Tom Sent: Wednesday, June 24, 2015 10:22 PM To: Dałek, Piotr; ceph-devel Subject: RE: deleting objects from a pool I've noticed that deleting objects from a basic k=2 m=1 erasure pool is much much slower than deleting a similar number of objects from a replicated size 3 pool (so the same number of files to be deleted). It looked like the ec pool object deletion was almost 20x slower. Is there a lot more work to be done to delete an ec pool object? -- Tom -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- ow...@vger.kernel.org] On Behalf Of Dalek, Piotr Sent: Wednesday, June 24, 2015 11:56 AM To: ceph-devel Subject: Re: deleting objects from a pool -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- ow...@vger.kernel.org] On Behalf Of Deneau, Tom Sent: Wednesday, June 24, 2015 6:44 PM I have benchmarking situations where I want to leave a pool around but delete a lot of objects from the pool. Is there any really fast way to do that? I noticed rados rmpool is fast but I don't want to remove the pool. I have been spawning multiple threads, each deleting a subset of the objects (which I believe is what rados bench write does) but even that can be very slow. For now, apart from "rados -p cleanup" (which doesn't purge the pool, but merely removes objects written during last benchmark run), the only option is by brute force: for i in $(rados -p ls); do (rados -p rm $i &>/dev/null &); done; There's no "purge pool" command in rados -- not yet, at least. I was thinking about one, but never really had time to implement one. With best regards / Pozdrawiam Piotr Dałek -- 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: RBD trim / unmap support?
hw/ide/qdev.c:error_report("discard_granularity must be 512 for ide");
> -Original Message-
> From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-
> ow...@vger.kernel.org] On Behalf Of Stefan Priebe - Profihost AG
> Sent: Freitag, 02. November 2012 09:20
> To: Josh Durgin
> Cc: ceph-devel@vger.kernel.org
> Subject: Re: RBD trim / unmap support?
>
> Am 02.11.2012 00:36, schrieb Josh Durgin:
> > On 11/01/2012 04:33 PM, Stefan Priebe wrote:
> >> Hello list,
> >>
> >> does rbd support trim / unmap? Or is it planned to support it?
> >>
> >> Greets,
> >> Stefan
> >
> > librbd (and thus qemu) support it. The rbd kernel module does not yet.
> > See http://ceph.com/docs/master/rbd/qemu-rbd/#enabling-discard-trim
>
> Thanks! Is there any recommanded value for discard_granularity? With
> fstrim and iscsi i use 128kb.
>
> Stefan
> --
> 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: CRC32 of messages
Thanks Piotr for the info, but I am not sure the asm instructions ceph is using for probing cpu is compatible to AMD or not. Regards Somnath -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Dalek, Piotr Sent: Sunday, June 28, 2015 11:27 PM To: ceph-devel@vger.kernel.org Subject: RE: CRC32 of messages > -Original Message- > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > ow...@vger.kernel.org] On Behalf Of Somnath Roy > Sent: Friday, June 26, 2015 7:52 PM > > ceph_crc32c_intel_fast is ~6 times faster than ceph_crc32c_sctp. If > you are not using intel cpus or you have older intel cpus where this > sse4 instruction Not exactly true, AMD CPUs released after October 2011 support SSE 4.2 (which include CRC32 instructions) as well. See this: http://www.cpu-world.com/Glossary/S/SSE4.2.html With best regards / Pozdrawiam Piotr Dałek -- 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 PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). -- 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: [Cluster-devel] [PATCH net-next] genetlink: start to validate reserved header bytes
On Wed, Aug 24, 2022 at 8:18 PM Jakub Kicinski wrote: > > We had historically not checked that genlmsghdr.reserved > is 0 on input which prevents us from using those precious > bytes in the future. > > One use case would be to extend the cmd field, which is > currently just 8 bits wide and 256 is not a lot of commands > for some core families. > > To make sure that new families do the right thing by default > put the onus of opting out of validation on existing families. > > Signed-off-by: Jakub Kicinski > --- > CC: j...@resnulli.us > CC: johan...@sipsolutions.net > CC: linux-bl...@vger.kernel.org > CC: osmocom-net-g...@lists.osmocom.org > CC: linux-w...@vger.kernel.org > CC: wiregu...@lists.zx2c4.com > CC: linux-wirel...@vger.kernel.org > CC: linux-s...@vger.kernel.org > CC: target-de...@vger.kernel.org > CC: linux...@vger.kernel.org > CC: virtualizat...@lists.linux-foundation.org > CC: linux-c...@vger.kernel.org > CC: cluster-devel@redhat.com > CC: mp...@lists.linux.dev > CC: lvs-de...@vger.kernel.org > CC: netfilter-de...@vger.kernel.org > CC: linux-security-mod...@vger.kernel.org > CC: d...@openvswitch.org > CC: linux-s...@vger.kernel.org > CC: tipc-discuss...@lists.sourceforge.net > --- > drivers/block/nbd.c | 1 + > drivers/net/gtp.c| 1 + > drivers/net/ieee802154/mac802154_hwsim.c | 1 + > drivers/net/macsec.c | 1 + > drivers/net/team/team.c | 1 + > drivers/net/wireguard/netlink.c | 1 + > drivers/net/wireless/mac80211_hwsim.c| 1 + > drivers/target/target_core_user.c| 1 + > drivers/thermal/thermal_netlink.c| 1 + > drivers/vdpa/vdpa.c | 1 + > fs/cifs/netlink.c| 1 + > fs/dlm/netlink.c | 1 + > fs/ksmbd/transport_ipc.c | 1 + > include/linux/genl_magic_func.h | 1 + > include/net/genetlink.h | 3 +++ > kernel/taskstats.c | 1 + > net/batman-adv/netlink.c | 1 + > net/core/devlink.c | 1 + > net/core/drop_monitor.c | 1 + > net/ethtool/netlink.c| 1 + > net/hsr/hsr_netlink.c| 1 + > net/ieee802154/netlink.c | 1 + > net/ieee802154/nl802154.c| 1 + > net/ipv4/fou.c | 1 + > net/ipv4/tcp_metrics.c | 1 + > net/ipv6/ila/ila_main.c | 1 + > net/ipv6/ioam6.c | 1 + > net/ipv6/seg6.c | 1 + > net/l2tp/l2tp_netlink.c | 1 + > net/mptcp/pm_netlink.c | 1 + > net/ncsi/ncsi-netlink.c | 1 + > net/netfilter/ipvs/ip_vs_ctl.c | 1 + > net/netlabel/netlabel_calipso.c | 1 + > net/netlabel/netlabel_cipso_v4.c | 1 + > net/netlabel/netlabel_mgmt.c | 1 + > net/netlabel/netlabel_unlabeled.c| 1 + > net/netlink/genetlink.c | 4 > net/nfc/netlink.c| 1 + > net/openvswitch/conntrack.c | 1 + > net/openvswitch/datapath.c | 3 +++ > net/openvswitch/meter.c | 1 + > net/psample/psample.c| 1 + > net/smc/smc_netlink.c| 3 ++- > net/smc/smc_pnet.c | 3 ++- > net/tipc/netlink.c | 1 + > net/tipc/netlink_compat.c| 1 + > net/wireless/nl80211.c | 1 + > 47 files changed, 56 insertions(+), 2 deletions(-) Acked-by: Paul Moore (NetLabel) -- paul-moore.com
[Assp-test] email processed when poTestMode=1 and recipient is not on processOnlyAddresses
poTestMode=1 recipi...@domain.com is not on processOnlyAddresses X-Assp-Version: 2.4.4(15106) bombReNP=0 following emails shold be noprocessing but are not for unknown reason. Why could that be? email 1: 2015-04-22 14:02:13 04133-2535013 [Worker_5] [TLS-in] 108.174.3.154 < s-4s34c6qkst1a7xh4me8si7x2g884salt6phzkawlq1dwlgxd3gu58...@bounce.linkedin.com> not delayed (gripvalue low: 0.31) 2015-04-22 14:02:13 04133-2535013 [Worker_5] [TLS-in] 108.174.3.154 < s-4s34c6qkst1a7xh4me8si7x2g884salt6phzkawlq1dwlgxd3gu58...@bounce.linkedin.com> to: recipi...@domain.com Message-Score: added -5 (spfpValencePB) for SPF pass, total score for this message is now -5 2015-04-22 14:02:14 04133-2535013 [Worker_5] [TLS-in] [MissingMX] 108.174.3.154 < s-4s34c6qkst1a7xh4me8si7x2g884salt6phzkawlq1dwlgxd3gu58...@bounce.linkedin.com> to: recipi...@domain.com [scoring] MX missing (cache): reply.linkedin.com 2015-04-22 14:02:14 04133-2535013 [Worker_5] [TLS-in] 108.174.3.154 < s-4s34c6qkst1a7xh4me8si7x2g884salt6phzkawlq1dwlgxd3gu58...@bounce.linkedin.com> to: recipi...@domain.com Message-Score: added 15 (mxValencePB) for MX missing (cache): reply.linkedin.com, total score for this message is now 10 2015-04-22 14:02:14 04133-2535013 [Worker_5] [TLS-in] 108.174.3.154 < s-4s34c6qkst1a7xh4me8si7x2g884salt6phzkawlq1dwlgxd3gu58...@bounce.linkedin.com> to: recipi...@domain.com Message-Score: added 50 (mxaValencePB) for A record missing: reply.linkedin.com (cache), total score for this message is now 60 2015-04-22 14:02:14 04133-2535013 [Worker_5] [TLS-in] [MissingMXA] 108.174.3.154 < s-4s34c6qkst1a7xh4me8si7x2g884salt6phzkawlq1dwlgxd3gu58...@bounce.linkedin.com> to: recipi...@domain.com MX and A record missing ( DoDomainCheck ) at least for: reply.linkedin.com 2015-04-22 14:02:14 04133-2535013 [Worker_5] [TLS-in] [MissingMXA] 108.174.3.154 < s-4s34c6qkst1a7xh4me8si7x2g884salt6phzkawlq1dwlgxd3gu58...@bounce.linkedin.com> to: recipi...@domain.com [spam found] (missing MX and A record) [Job opportunity in UK] -> /usr/assp/spam/Job_opportunity_in_UK--202201.eml; email 2: 2015-04-22 16:33:43 13223-1891995 [Worker_2] 209.132.180.67 < netdev-ow...@vger.kernel.org> info: found message size announcement: 4.44 kByte 2015-04-22 16:33:44 13223-1891995 [Worker_2] 209.132.180.67 < netdev-ow...@vger.kernel.org> renewing tuplet: (209.132.180.0, vger.kernel.org) age: 7m 38s 2015-04-22 16:33:44 13223-1891995 [Worker_2] 209.132.180.67 < netdev-ow...@vger.kernel.org> to: recipi...@domain.com spambomb Regex: bombDataRe 'PB 25: for refill' 2015-04-22 16:33:44 13223-1891995 [Worker_2] [BombData] 209.132.180.67 < netdev-ow...@vger.kernel.org> to: recipi...@domain.com [scoring] (BombData 'refill') 2015-04-22 16:33:44 13223-1891995 [Worker_2] 209.132.180.67 < netdev-ow...@vger.kernel.org> to: recipi...@domain.com Message-Score: added 25 for Regex: bombDataRe 'PB 25: for refill' BombData: 'refill', total score for this message is now 25 2015-04-22 16:33:44 13223-1891995 [Worker_2] 209.132.180.67 < netdev-ow...@vger.kernel.org> to: recipi...@domain.com spambomb Regex: bombRe 'PB 25: for refill' 2015-04-22 16:33:44 13223-1891995 [Worker_2] [BombData][bombRe] 209.132.180.67 to: recipi...@domain.com [scoring] (bombRe 'refill') 2015-04-22 16:33:44 13223-1891995 [Worker_2] 209.132.180.67 < netdev-ow...@vger.kernel.org> to: recipi...@domain.com Message-Score: added 25 for Regex: bombRe 'PB 25: for refill' bombRe: 'refill', total score for this message is now 50 2015-04-22 16:33:44 13223-1891995 [Worker_2] 209.132.180.67 < netdev-ow...@vger.kernel.org> to: recipi...@domain.com deleting spamming safelisted tuplet: (209.132.180.0,vger.kernel.org) age: 0s 2015-04-22 16:33:44 13223-1891995 [Worker_2] [MessageLimit] 209.132.180.67 < netdev-ow...@vger.kernel.org> to: recipi...@domain.com [spam found] (MessageScore 50, limit 50) [PATCH net net do not deplete pfmemalloc reserve] -> /usr/assp/spam/PATCH_net_net_do_not_deplete_p--204838.eml; email 3: 2015-04-14 07:34:54 89694-1314237 [Worker_2] [NoProcessing] 185.38.248.49 < retzqug7fb5dwqprwxg5...@emailmarketingonline.eu> to: recipi...@domain.com message proxied without processing (except checks enabled for noprocessing mails) 2015-04-14 07:34:55 89694-1314237 [Worker_2] 185.38.248.49 < retzqug7fb5dwqprwxg5...@emailmarketingonline.eu> to: recipi...@domain.com spambomb Regex: blackRe 'PB 25: for freshmail.pl' 2015-04-14 07:34:55 89694-1314237 [Worker_2] [BombBlack] 185.38.248.49 < retzqug7fb5dwqprwxg5...@emailmarketingonline.eu> to: recipi...@domain.com (BombBlack 'freshmail.pl') 2015-04-14 07:34:55 89694-1314237 [Worker_2] 185.38.248.49 < retzqug7fb5dwqprwxg5...@emailmarketingonline.eu> to: recipi...@domain.com Message-Score: added 25 for BombBlack 'freshmail.pl', total score for this message i
RE: deleting objects from a pool
Hi David, You're right, now I see adding --run-name "" will clean all benchmark data from specified namespace, so you can run command only once. rados -p -N cleanup --prefix "" --run-name "" Regards, Igor. -Original Message- From: David Zafman [mailto:dzaf...@redhat.com] Sent: Friday, June 26, 2015 3:46 AM To: Podoski, Igor; Deneau, Tom; Dałek, Piotr; ceph-devel Subject: Re: deleting objects from a pool If you have rados bench data around, you'll need to run cleanup a second time because the first time the "benchmark_last_metadata" object will be consulted to find what objects to remove. Also, using cleanup this way will only remove objects from the default namespace unless a namespace is specified with the -N option. rados -p -N cleanup --prefix "" David On 6/24/15 11:06 PM, Podoski, Igor wrote: > Hi, > > It appears, that cleanup can be used as a purge: > > rados -p cleanup --prefix "" > > Regards, > Igor. > > > -Original Message- > From: ceph-devel-ow...@vger.kernel.org > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Deneau, Tom > Sent: Wednesday, June 24, 2015 10:22 PM > To: Dałek, Piotr; ceph-devel > Subject: RE: deleting objects from a pool > > I've noticed that deleting objects from a basic k=2 m=1 erasure pool is much > much slower than deleting a similar number of objects from a replicated size > 3 pool (so the same number of files to be deleted). It looked like the ec > pool object deletion was almost 20x slower. Is there a lot more work to be > done to delete an ec pool object? > > -- Tom > > > >> -Original Message- >> From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- >> ow...@vger.kernel.org] On Behalf Of Dalek, Piotr >> Sent: Wednesday, June 24, 2015 11:56 AM >> To: ceph-devel >> Subject: Re: deleting objects from a pool >> >>> -Original Message- >>> From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- >>> ow...@vger.kernel.org] On Behalf Of Deneau, Tom >>> Sent: Wednesday, June 24, 2015 6:44 PM >>> >>> I have benchmarking situations where I want to leave a pool around >>> but delete a lot of objects from the pool. Is there any really fast >>> way to do >> that? >>> I noticed rados rmpool is fast but I don't want to remove the pool. >>> >>> I have been spawning multiple threads, each deleting a subset of the >> objects >>> (which I believe is what rados bench write does) but even that can >>> be very slow. >> For now, apart from "rados -p cleanup" (which doesn't >> purge the pool, but merely removes objects written during last >> benchmark run), the only option is by brute force: >> >> for i in $(rados -p ls); do (rados -p rm $i >> &>/dev/null &); done; >> >> There's no "purge pool" command in rados -- not yet, at least. I was >> thinking about one, but never really had time to implement one. >> >> With best regards / Pozdrawiam >> Piotr Dałek >> -- >> 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: v2 aligned buffer changes for erasure codes
Hi Janne/Loic, there is more confusion atleast on my side ... I had now a look at the jerasure plug-in and I am now slightly confused why you have two ways to return in get_alignment ... one is as I assume and another one is "per_chunk_alignment" ... what should the function return Loic? Cheers Andreas. From: ceph-devel-ow...@vger.kernel.org [ceph-devel-ow...@vger.kernel.org] on behalf of Andreas Joachim Peters [andreas.joachim.pet...@cern.ch] Sent: 18 September 2014 14:18 To: Janne Grunau; ceph-devel@vger.kernel.org Subject: RE: v2 aligned buffer changes for erasure codes Hi Janne, => (src/erasure-code/isa/README claims it needs 16*k byte aligned buffers I should update the README since it is misleading ... it should say 8*k or 16*k byte aligned chunk size depending on the compiler/platform used, it is not the alignment of the allocated buffer addresses.The get_alignment in the plug-in function is used to compute the chunk size for the encoding (as I said not the start address alignment). If you pass k buffers for decoding each buffer should be aligned at least to 16 or as you pointed out better 32 bytes. For encoding there is normally a single buffer split 'virtually' into k pieces. To make all pieces starting at an aligned address one needs to align the chunk size to e.g. 16*k. For the best possible performance on all platforms we should change the get_alignment function in the ISA plug-in to return 32*k if there are no other objections ?!?! Cheers Andreas. From: ceph-devel-ow...@vger.kernel.org [ceph-devel-ow...@vger.kernel.org] on behalf of Janne Grunau [j...@jannau.net] Sent: 18 September 2014 12:33 To: ceph-devel@vger.kernel.org Subject: v2 aligned buffer changes for erasure codes Hi, following a is an updated patchset. It passes now make check in src It has following changes: * use 32-byte alignment since the isa plugin use AVX2 (src/erasure-code/isa/README claims it needs 16*k byte aligned buffers but I can't see a reason why it would need more than 32-bytes * ErasureCode::encode_prepare() handles more than one chunk with padding cheers Janne -- 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: [Bridge] [PATCH bpf-next v2] net: don't include filter.h from net/sock.h
On 29/12/2021 02:49, Jakub Kicinski wrote: > sock.h is pretty heavily used (5k objects rebuilt on x86 after > it's touched). We can drop the include of filter.h from it and > add a forward declaration of struct sk_filter instead. > This decreases the number of rebuilt objects when bpf.h > is touched from ~5k to ~1k. > > There's a lot of missing includes this was masking. Primarily > in networking tho, this time. > > Acked-by: Marc Kleine-Budde > Signed-off-by: Jakub Kicinski > --- > v2: https://lore.kernel.org/all/20211228192519.386913-1-k...@kernel.org/ > - fix build in bond on ia64 > - fix build in ip6_fib with randconfig > > CC: mar...@holtmann.org > CC: johan.hedb...@gmail.com > CC: luiz.de...@gmail.com > CC: dledf...@redhat.com > CC: j...@ziepe.ca > CC: mustafa.ism...@intel.com > CC: shiraz.sal...@intel.com > CC: l...@kernel.org > CC: ap420...@gmail.com > CC: w...@grandegger.com > CC: woojung@microchip.com > CC: and...@lunn.ch > CC: vivien.dide...@gmail.com > CC: f.faine...@gmail.com > CC: olte...@gmail.com > CC: george.mccollis...@gmail.com > CC: michael.c...@broadcom.com > CC: jesse.brandeb...@intel.com > CC: anthony.l.ngu...@intel.com > CC: a...@kernel.org > CC: dan...@iogearbox.net > CC: h...@kernel.org > CC: john.fastab...@gmail.com > CC: tar...@nvidia.com > CC: sae...@nvidia.com > CC: ecree.xil...@gmail.com > CC: habetsm.xil...@gmail.com > CC: jreu...@yaina.de > CC: dsah...@kernel.org > CC: kv...@codeaurora.org > CC: pks...@realtek.com > CC: trond.mykleb...@hammerspace.com > CC: anna.schuma...@netapp.com > CC: v...@zeniv.linux.org.uk > CC: and...@kernel.org > CC: mcg...@kernel.org > CC: keesc...@chromium.org > CC: yzai...@google.com > CC: niko...@nvidia.com > CC: j...@nvidia.com > CC: wint...@linux.ibm.com > CC: wen...@linux.ibm.com > CC: pa...@netfilter.org > CC: kad...@netfilter.org > CC: f...@strlen.de > CC: r...@linux-mips.org > CC: j...@mojatatu.com > CC: xiyou.wangc...@gmail.com > CC: kgr...@linux.ibm.com > CC: sgarz...@redhat.com > CC: steffen.klass...@secunet.com > CC: herb...@gondor.apana.org.au > CC: a...@arndb.de > CC: linux-blueto...@vger.kernel.org > CC: linux-r...@vger.kernel.org > CC: linux-...@vger.kernel.org > CC: intel-wired-...@lists.osuosl.org > CC: b...@vger.kernel.org > CC: linux-h...@vger.kernel.org > CC: ath...@lists.infradead.org > CC: linux-wirel...@vger.kernel.org > CC: linux-...@vger.kernel.org > CC: linux-fsde...@vger.kernel.org > CC: bridge@lists.linux-foundation.org > CC: linux-decnet-u...@lists.sourceforge.net > CC: linux-s...@vger.kernel.org > CC: netfilter-de...@vger.kernel.org > CC: coret...@netfilter.org > CC: virtualizat...@lists.linux-foundation.org > --- [snip] > net/bridge/br_ioctl.c | 1 + [snip > 70 files changed, 80 insertions(+), 1 deletion(-) > For the bridge: Acked-by: Nikolay Aleksandrov
Re: OSD crashed today in os/JournalingObjectStore.cc
Hi Stefan, I've pushed a few patches to wip-filestore2 that simplify and fix this code. Can you give it a go? Thanks! sage On Thu, 6 Dec 2012, Stefan Priebe - Profihost AG wrote: > Hi, > > here a new dump / crash: > https://www.dropbox.com/s/1qhg0dd0fv17q10/ceph-osd.54.log.gz > > Stefan > > Am 06.12.2012 00:36, schrieb Sage Weil: > > On Wed, 5 Dec 2012, Stefan Priebe - Profihost AG wrote: > > > There was a dump in the attached log. > > > > The stack trace is there, but with 'debug journal = 0/20' in your conf it > > will also dump all of the journal logging activity leading up to that > > point. Can you reproduce with that enabled? That should tell me why op < > > commited_seq. > > > > Thanks! > > sage > > > > > > > > > > Stefan > > > > > > Am 05.12.2012 um 15:41 schrieb Sage Weil : > > > > > > > On Wed, 5 Dec 2012, Stefan Priebe - Profihost AG wrote: > > > > > Hello list, > > > > > > > > > > i updated to latest next from today and then after 20 minutes an OSD > > > > > was > > > > > crashing in os/JournalingObjectStore.cc. > > > > > > > > > > Attached is the log. > > > > > > > > Hmm, this is perplexing. It might just be a bad assert, but I can't see > > > > how it could happen. Any chance you can reproduce with > > > > > > > > debug journal = 0/10 > > > > > > > > in the [osd] section? That will give us a dump if it fails the assert. > > > > > > > > Thanks! > > > > s > > > > -- > > > > 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 > > -- 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: Random blocks when accessing rbd images
On 12/16/2011 10:17 PM, Samuel Just wrote: In master, 061e7619aacf60a828e0ce84a108d5a0bea247c6 may fix the problem. If not, 5274e88d2cb8c0449a4ecd1ff0cf8bb0af2cfc97 includes some asserts that may give us a clue as to how this is happening. I've been running with bfbde5b18525406fc3b678751459e989ea5d4977 for over 24 hours now, everything is still active+clean. If it comes back I'll update this thread. Thanks, Wido -Sam On Fri, Dec 16, 2011 at 8:17 AM, Wido den Hollander wrote: Hi, On 12/15/2011 05:44 PM, Martin Mailand wrote: Hi, at least there is a patch that should have fixed it. http://marc.info/?l=ceph-devel&m=131955913203561&w=2 I'm still seeing this one: 2011-12-16 17:14:53.638722pg v1170309: 7808 pgs: 7807 active+clean, 1 active+clean+scrubbing; 15279 MB data, 47262 MB used, 73838 GB / 74520 GB avail In this case PG "2.688" is in scrubbing state and is staying that way. I'm running v0.39, not the latest master. Any suggestions to trace this one down? Wido Am 15.12.2011 17:38, schrieb Martin Mailand: Hi Wido, but wasn't that fixed a few weeks ago? -martin Am 15.12.2011 17:33, schrieb Wido den Hollander: Yes, from what I've seen it will block indefinitely until you restart one of the OSDs who are member of the PG. Wido -- 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 -- 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: rbd export to stdout ?
note: import for stdin already work: rbd import --size=xxx - image < stdin from this patch http://permalink.gmane.org/gmane.comp.file-systems.ceph.devel/6315 - Mail original - De: "Alexandre DERUMIER" À: "Wido den Hollander" Cc: ceph-devel@vger.kernel.org Envoyé: Lundi 22 Octobre 2012 14:25:33 Objet: Re: rbd export to stdout ? ok, thanks Wido. Regards, Alexandre - Mail original - De: "Wido den Hollander" À: "Alexandre DERUMIER" Cc: ceph-devel@vger.kernel.org Envoyé: Lundi 22 Octobre 2012 13:58:40 Objet: Re: rbd export to stdout ? On 10/22/2012 12:41 PM, Alexandre DERUMIER wrote: > Hi, > > I'm looking for use "rbd export " to stdout and not a file. > > Is it possible ? any hint ? > No, not at this moment. I tried a fifo, but that won't work due to O_EXCL and O_CREATE the rbd command uses. I think it should be possible to export to stdout, but it will require some code changes. I created a feature request for it: http://tracker.newdream.net/issues/3380 Wido > Regards, > > Alexandre Derumier > -- > 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: rbd create issues - like the bug...
Nevermind. One OSD node was missing the lib. Cheers! -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Ryan Nicholson Sent: Tuesday, July 31, 2012 9:05 PM To: ceph-devel@vger.kernel.org Subject: RE: rbd create issues - like the bug... All: I cannot get this to work: Rbd create testImage --size 2000 My ceph.conf. file contains # [osd] osd_class_dir = /usr/local/lib/rados-classes # I've added /usr/local/lib/rados-classes to my ld.so.conf I've done a ldconfig. libcls_rbd.so & so.1 & so.1.0.0 are in the cache. (ldconfig -p | grep ...) However, I'm still getting the error noted here http://ceph.com/docs/master/dev/osd-class-path/ [librbd: failed to assign a block name for image] Not sure where to go next... Thanks, for any help. Ryan Nicholson -- 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: Cache tiering slow request issue: currently waiting for rw locks
Pasting the conversations in the pull request here. wonzhq commented 6 days ago If checking ObjectContext::RWState::waiters and ObjectContext::RWState::count for the pending requests on this object, there is still a window which the problem can happen. That is after the promotion replication and requeuing the client request, and before dequeuing the client request. Should we loop the OSD::op_wq to check the pending requests on an object? Or adding something in the ObjectContext to remember the pending requests? @athanatos @liewegas liewegas commented 10 hours ago Hmm, that's true that there is still that window. Is it necessary that this is completely air-tight, though? As long as we avoid evicting a newly-promoted object before the request is processed we will win. I'm afraid that a complicated mechanism to cover this could introduce more complexity than we need. wonzhq commented 2 minutes ago Tried to use ObjectContext::RWState::count to check the pending request. In my testing, it hit the slow request just once. I checked the log, it exactly falls into the window we talked above. So with this solution, it's possible that we still hit this issue, but much less than before. Should we go ahead with this solution? Sage/Sam, what do you think? -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Wang, Zhiqiang Sent: Friday, September 5, 2014 3:21 PM To: Sage Weil; 'sam.j...@inktank.com' Cc: 'ceph-devel@vger.kernel.org' Subject: RE: Cache tiering slow request issue: currently waiting for rw locks I made some comments based on your comments of the pull request https://github.com/ceph/ceph/pull/2374. Can you take a look? Thx. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Wang, Zhiqiang Sent: Tuesday, September 2, 2014 2:54 PM To: Sage Weil Cc: 'ceph-devel@vger.kernel.org' Subject: RE: Cache tiering slow request issue: currently waiting for rw locks Tried the pull request, checking the object is blocked or not doesn't work. Actually this check is already done in function agent_work. I tried to make a fix to add a field/flag to the object context. This is not a good idea for the following reasons: 1) If making this filed/flag to be a persistent one, when resetting/clearing this flag, we need to persist it. This is not good for read request. 2) If making this field/flag not to be a persistent one, when the object context is removed from the cache ' object_contexts', this field/flag is removed as well. This object is removed in the later evicting. The same issue still exists. So, I came up with a fix to add a set in the class ReplicatedPG to hold all the promoting objects. This fix is at https://github.com/ceph/ceph/pull/2374. It is tested and works well. Pls review and comment, thx. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Wang, Zhiqiang Sent: Monday, September 1, 2014 9:33 AM To: Sage Weil Cc: 'ceph-devel@vger.kernel.org' Subject: RE: Cache tiering slow request issue: currently waiting for rw locks I don't think the object context is blocked at that time. It is un-blocked after the copying of data from base tier. It doesn't address the problem here. Anyway, I'll try it and see. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil Sent: Saturday, August 30, 2014 10:29 AM To: Wang, Zhiqiang Cc: 'ceph-devel@vger.kernel.org' Subject: Re: Cache tiering slow request issue: currently waiting for rw locks Hi, Can you take a look at https://github.com/ceph/ceph/pull/2363 and see if that addresses the behavior you saw? Thanks! sage On Fri, 29 Aug 2014, Sage Weil wrote: > Hi, > > I've opened http://tracker.ceph.com/issues/9285 to track this. > > I think you're right--we need a check in agent_maybe_evict() that will > skip objects that are being promoted. I suspect a flag on the > ObjectContext is enough? > > sage > > > On Fri, 29 Aug 2014, Wang, Zhiqiang wrote: > > > Hi all, > > > > I've ran into this slow request issue some time ago. The problem is like > > this: when running with cache tieing, there are 'slow request' warning > > messages in the log file like below. > > > > 2014-08-29 10:18:24.669763 7f9b20f1b700 0 log [WRN] : 1 slow > > requests, 1 included below; oldest blocked for > 30.996595 secs > > 2014-08-29 10:18:24.669768 7f9b20f1b700 0 log [WRN] : slow request > > 30.996595 seconds old, received at 2014-08-29 10:17:53.673142: > > osd_op(client.114176.0:144919 rb.0.17f56.6b8b4567.0935 > > [sparse-read 3440640
[Cluster-devel] [PATCH v13 0/5] overlayfs override_creds=off
Patch series: overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh Add flags option to get xattr method paired to __vfs_getxattr overlayfs: handle XATTR_NOSECURITY flag for get xattr method overlayfs: internal getxattr operations without sepolicy checking overlayfs: override_creds=off option bypass creator_cred The first four patches address fundamental security issues that should be solved regardless of the override_creds=off feature. on them). The fifth adds the feature depends on these other fixes. By default, all access to the upper, lower and work directories is the recorded mounter's MAC and DAC credentials. The incoming accesses are checked against the caller's credentials. If the principles of least privilege are applied for sepolicy, the mounter's credentials might not overlap the credentials of the caller's when accessing the overlayfs filesystem. For example, a file that a lower DAC privileged caller can execute, is MAC denied to the generally higher DAC privileged mounter, to prevent an attack vector. We add the option to turn off override_creds in the mount options; all subsequent operations after mount on the filesystem will be only the caller's credentials. The module boolean parameter and mount option override_creds is also added as a presence check for this "feature", existence of /sys/module/overlay/parameters/overlay_creds Signed-off-by: Mark Salyzyn Cc: Miklos Szeredi Cc: Jonathan Corbet Cc: Vivek Goyal Cc: Eric W. Biederman Cc: Amir Goldstein Cc: Randy Dunlap Cc: Stephen Smalley Cc: linux-unio...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Eric Van Hensbergen Cc: Latchesar Ionkov Cc: Dominique Martinet Cc: David Howells Cc: Chris Mason Cc: Josef Bacik Cc: David Sterba Cc: Jeff Layton Cc: Sage Weil Cc: Ilya Dryomov Cc: Steve French Cc: Tyler Hicks Cc: Jan Kara Cc: Theodore Ts'o Cc: Andreas Dilger Cc: Jaegeuk Kim Cc: Chao Yu Cc: Bob Peterson Cc: Andreas Gruenbacher Cc: David Woodhouse Cc: Richard Weinberger Cc: Dave Kleikamp Cc: Greg Kroah-Hartman Cc: Tejun Heo Cc: Trond Myklebust Cc: Anna Schumaker Cc: Mark Fasheh Cc: Joel Becker Cc: Joseph Qi Cc: Mike Marshall Cc: Martin Brandenburg Cc: Alexander Viro Cc: Phillip Lougher Cc: Darrick J. Wong Cc: linux-...@vger.kernel.org Cc: Hugh Dickins Cc: David S. Miller Cc: Andrew Morton Cc: Mathieu Malaterre Cc: Ernesto A. Fernández Cc: Vyacheslav Dubeyko Cc: v9fs-develo...@lists.sourceforge.net Cc: linux-...@lists.infradead.org Cc: linux-bt...@vger.kernel.org Cc: ceph-de...@vger.kernel.org Cc: linux-c...@vger.kernel.org Cc: samba-techni...@lists.samba.org Cc: ecryp...@vger.kernel.org Cc: linux-e...@vger.kernel.org Cc: linux-f2fs-de...@lists.sourceforge.net Cc: linux-fsde...@vger.kernel.org Cc: cluster-devel@redhat.com Cc: linux-...@lists.infradead.org Cc: jfs-discuss...@lists.sourceforge.net Cc: linux-...@vger.kernel.org Cc: ocfs2-de...@oss.oracle.com Cc: de...@lists.orangefs.org Cc: reiserfs-de...@vger.kernel.org Cc: linux...@kvack.org Cc: net...@vger.kernel.org Cc: linux-security-mod...@vger.kernel.org Cc: sta...@vger.kernel.org # 4.4, 4.9, 4.14 & 4.19 --- v13: - add flags argument to __vfs_getxattr - drop GFP_NOFS side-effect v12: - Restore squished out patch 2 and 3 in the series, then change algorithm to add flags argument. Per-thread flag is a large security surface. v11: - Squish out v10 introduced patch 2 and 3 in the series, then and use per-thread flag instead for nesting. - Switch name to ovl_do_vds_getxattr for __vds_getxattr wrapper. - Add sb argument to ovl_revert_creds to match future work. v10: - Return NULL on CAP_DAC_READ_SEARCH - Add __get xattr method to solve sepolicy logging issue - Drop unnecessary sys_admin sepolicy checking for administrative driver internal xattr functions. v6: - Drop CONFIG_OVERLAY_FS_OVERRIDE_CREDS. - Do better with the documentation, drop rationalizations. - pr_warn message adjusted to report consequences. v5: - beefed up the caveats in the Documentation - Is dependent on "overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh" "overlayfs: check CAP_MKNOD before issuing vfs_whiteout" - Added prwarn when override_creds=off v4: - spelling and grammar errors in text v3: - Change name from caller_credentials / creator_credentials to the boolean override_creds. - Changed from creator to mounter credentials. - Updated and fortified the documentation. - Added CONFIG_OVERLAY_FS_OVERRIDE_CREDS v2: - Forward port changed attr to stat, resulting in a build error. - altered commit message.
[Cluster-devel] [PATCH v13 0/5] overlayfs override_creds=off
Patch series: overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh Add flags option to get xattr method paired to __vfs_getxattr overlayfs: handle XATTR_NOSECURITY flag for get xattr method overlayfs: internal getxattr operations without sepolicy checking overlayfs: override_creds=off option bypass creator_cred The first four patches address fundamental security issues that should be solved regardless of the override_creds=off feature. on them). The fifth adds the feature depends on these other fixes. By default, all access to the upper, lower and work directories is the recorded mounter's MAC and DAC credentials. The incoming accesses are checked against the caller's credentials. If the principles of least privilege are applied for sepolicy, the mounter's credentials might not overlap the credentials of the caller's when accessing the overlayfs filesystem. For example, a file that a lower DAC privileged caller can execute, is MAC denied to the generally higher DAC privileged mounter, to prevent an attack vector. We add the option to turn off override_creds in the mount options; all subsequent operations after mount on the filesystem will be only the caller's credentials. The module boolean parameter and mount option override_creds is also added as a presence check for this "feature", existence of /sys/module/overlay/parameters/overlay_creds Signed-off-by: Mark Salyzyn Cc: Miklos Szeredi Cc: Jonathan Corbet Cc: Vivek Goyal Cc: Eric W. Biederman Cc: Amir Goldstein Cc: Randy Dunlap Cc: Stephen Smalley Cc: linux-unio...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Eric Van Hensbergen Cc: Latchesar Ionkov Cc: Dominique Martinet Cc: David Howells Cc: Chris Mason Cc: Josef Bacik Cc: David Sterba Cc: Jeff Layton Cc: Sage Weil Cc: Ilya Dryomov Cc: Steve French Cc: Tyler Hicks Cc: Jan Kara Cc: Theodore Ts'o Cc: Andreas Dilger Cc: Jaegeuk Kim Cc: Chao Yu Cc: Bob Peterson Cc: Andreas Gruenbacher Cc: David Woodhouse Cc: Richard Weinberger Cc: Dave Kleikamp Cc: Greg Kroah-Hartman Cc: Tejun Heo Cc: Trond Myklebust Cc: Anna Schumaker Cc: Mark Fasheh Cc: Joel Becker Cc: Joseph Qi Cc: Mike Marshall Cc: Martin Brandenburg Cc: Alexander Viro Cc: Phillip Lougher Cc: Darrick J. Wong Cc: linux-...@vger.kernel.org Cc: Hugh Dickins Cc: David S. Miller Cc: Andrew Morton Cc: Mathieu Malaterre Cc: Ernesto A. Fernandez Cc: Vyacheslav Dubeyko Cc: v9fs-develo...@lists.sourceforge.net Cc: linux-...@lists.infradead.org Cc: linux-bt...@vger.kernel.org Cc: ceph-de...@vger.kernel.org Cc: linux-c...@vger.kernel.org Cc: samba-techni...@lists.samba.org Cc: ecryp...@vger.kernel.org Cc: linux-e...@vger.kernel.org Cc: linux-f2fs-de...@lists.sourceforge.net Cc: linux-fsde...@vger.kernel.org Cc: cluster-devel@redhat.com Cc: linux-...@lists.infradead.org Cc: jfs-discuss...@lists.sourceforge.net Cc: linux-...@vger.kernel.org Cc: ocfs2-de...@oss.oracle.com Cc: de...@lists.orangefs.org Cc: reiserfs-de...@vger.kernel.org Cc: linux...@kvack.org Cc: net...@vger.kernel.org Cc: linux-security-mod...@vger.kernel.org Cc: sta...@vger.kernel.org # 4.4, 4.9, 4.14 & 4.19 --- v13: - add flags argument to __vfs_getxattr - drop GFP_NOFS side-effect v12: - Restore squished out patch 2 and 3 in the series, then change algorithm to add flags argument. Per-thread flag is a large security surface. v11: - Squish out v10 introduced patch 2 and 3 in the series, then and use per-thread flag instead for nesting. - Switch name to ovl_do_vds_getxattr for __vds_getxattr wrapper. - Add sb argument to ovl_revert_creds to match future work. v10: - Return NULL on CAP_DAC_READ_SEARCH - Add __get xattr method to solve sepolicy logging issue - Drop unnecessary sys_admin sepolicy checking for administrative driver internal xattr functions. v6: - Drop CONFIG_OVERLAY_FS_OVERRIDE_CREDS. - Do better with the documentation, drop rationalizations. - pr_warn message adjusted to report consequences. v5: - beefed up the caveats in the Documentation - Is dependent on "overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh" "overlayfs: check CAP_MKNOD before issuing vfs_whiteout" - Added prwarn when override_creds=off v4: - spelling and grammar errors in text v3: - Change name from caller_credentials / creator_credentials to the boolean override_creds. - Changed from creator to mounter credentials. - Updated and fortified the documentation. - Added CONFIG_OVERLAY_FS_OVERRIDE_CREDS v2: - Forward port changed attr to stat, resulting in a build error. - altered commit message.
RE: Pull Request for ISA EC plug-in
Ok,
I fixed the 'make dist' problem and hopefully also the YASM include problem.
The CEPH yasm-wrapper was removing '-I' from the options passed to yasm, so
'-I' didn't work without patching the wrapper itself.
I looked into YASM 1.1 and I found that at a certain patch version they fixed
the behaviour for relative -I paths, so I use now "-I $(abs_srcdir)" hoping
that this works with both YASM versions.
Let me know,
thanks Andreas.
________
From: ceph-devel-ow...@vger.kernel.org [ceph-devel-ow...@vger.kernel.org] on
behalf of Andreas Joachim Peters [andreas.joachim.pet...@cern.ch]
Sent: 31 July 2014 09:39
To: Sage Weil; Ma, Jianpeng
Cc: ceph-devel@vger.kernel.org
Subject: RE: Pull Request for ISA EC plug-in
Ok,
thanks for looking into that.
I am fixing the 'make dist' target and will try to make it work also with yasm
1.1 ...
Will let you know when to retry ...
Andreas.
____
From: ceph-devel-ow...@vger.kernel.org [ceph-devel-ow...@vger.kernel.org] on
behalf of Sage Weil [sw...@redhat.com]
Sent: 31 July 2014 07:27
To: Ma, Jianpeng
Cc: Andreas Joachim Peters; ceph-devel@vger.kernel.org
Subject: RE: Pull Request for ISA EC plug-in
On Thu, 31 Jul 2014, Ma, Jianpeng wrote:
> Hi,
>At my machine, I also met this bug. But I modify this, it can work.
> diff --git a/src/erasure-code/isa/Makefile.am
> b/src/erasure-code/isa/Makefile.am
> index eebffea..dee593b 100644
> --- a/src/erasure-code/isa/Makefile.am
> +++ b/src/erasure-code/isa/Makefile.am
> @@ -34,7 +34,7 @@ libec_isa_la_SOURCES = ${isa_sources}
>
> libec_isa_la_CFLAGS = ${AM_CFLAGS} -I
> $(srcdir)/erasure-code/isa/isa-l/include/
> libec_isa_la_CXXFLAGS = ${AM_CXXFLAGS} -I
> $(srcdir)/erasure-code/isa/isa-l/include/
> -libec_isa_la_CCASFLAGS = ${AM_CCASFLAGS} -I
> $(srcdir)/erasure-code/isa/isa-l/include/
> +libec_isa_la_CCASFLAGS = ${AM_CCASFLAGS} -i
> $(srcdir)/erasure-code/isa/isa-l/include
>
> libec_isa_la_LIBADD = $(LIBCRUSH) $(PTHREAD_LIBS) $(EXTRALIBS)
> libec_isa_la_LDFLAGS = ${AM_LDFLAGS} -version-info 2:10:0
>
>
> As Andreas said, the different is -I and -i.
> But how to choose? My yasm version is 1.2.0.
Ah, my machine with 1.2 is behaving. I think it's a combination of that,
and that the files are not all include in the 'make dist' tarball.
sage
>
> Thanks!
>
>
>
> > -Original Message-
> > From: ceph-devel-ow...@vger.kernel.org
> > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil
> > Sent: Thursday, July 31, 2014 7:02 AM
> > To: Andreas Joachim Peters
> > Cc: ceph-devel@vger.kernel.org
> > Subject: RE: Pull Request for ISA EC plug-in
> >
> > On Wed, 30 Jul 2014, Andreas Joachim Peters wrote:
> > > Hi Sage,
> > >
> > > my guess it comes from the yasm include option which evt. is
> > > non-standard. Mine documents '-i' and '-I' while I found on the web
> > > that probably only '-I' is the portable one.
> > >
> > > I have changed that, still I can only guess, since I cannot reproduce.
> >
> > Hmm, how are you building it? Running make on my work box (precise) also
> > fails. I modified yasm-wrapper slightly[1] and it's gets further, but
> > still no
> > dice...
> >
> > Thanks!
> > sage
> >
> >
> > [1] https://github.com/ceph/ceph/commit/wip-ec-isa
> >
> >
> > >
> > > Please rerun.
> > >
> > > Thanks, Andreas.
> > >
> > >
> > > From: Sage Weil [sw...@redhat.com]
> > > Sent: 30 July 2014 19:46
> > > To: Andreas Joachim Peters
> > > Cc: ceph-devel@vger.kernel.org
> > > Subject: RE: Pull Request for ISA EC plug-in
> > >
> > > On Mon, 28 Jul 2014, Andreas Joachim Peters wrote:
> > > > Hi Sage,
> > > >
> > > > I fixed that. I missed '$(srcdir)' in the assembler and C/C++
> > > > include statements (I always compiled in src dir ..)
> > > >
> > > > You can retry.
> > >
> > > I think there are still a few issues:
> > >
> > > make[4]: ***
> > > [erasure-code/isa/isa-l/erasure_code/libec_isa_la-ec_base.lo] Error 1
> > > make[4]: *** Waiting for unfinished jobs
> > > ./yasm-wrapper: yasm -f elf64 -i ./erasure-code/isa/isa-l/include/
> > > erasure-code/isa/isa-l/erasure_code/ec_multibinary.asm.s -o
> > > erasure-code/isa/isa-l/erasure_code/.libs/libec_isa_la-ec_multibinary.
> > > asm.o
> > > FATAL:
Re: deleting objects from a pool
This is a dangerous command because it can remove all your objects. At least it can only do one namespace at a time. It was intended to cleanup rados bench runs, and is dangerous because it doesn't require extra hoops like rados rmpool does. I'm tempted to disallow a usage this way with empty --prefix/--run-name arguments. David On 6/25/15 10:40 PM, Podoski, Igor wrote: Hi David, You're right, now I see adding --run-name "" will clean all benchmark data from specified namespace, so you can run command only once. rados -p -N cleanup --prefix "" --run-name "" Regards, Igor. -Original Message- From: David Zafman [mailto:dzaf...@redhat.com] Sent: Friday, June 26, 2015 3:46 AM To: Podoski, Igor; Deneau, Tom; Dałek, Piotr; ceph-devel Subject: Re: deleting objects from a pool If you have rados bench data around, you'll need to run cleanup a second time because the first time the "benchmark_last_metadata" object will be consulted to find what objects to remove. Also, using cleanup this way will only remove objects from the default namespace unless a namespace is specified with the -N option. rados -p -N cleanup --prefix "" David On 6/24/15 11:06 PM, Podoski, Igor wrote: Hi, It appears, that cleanup can be used as a purge: rados -p cleanup --prefix "" Regards, Igor. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Deneau, Tom Sent: Wednesday, June 24, 2015 10:22 PM To: Dałek, Piotr; ceph-devel Subject: RE: deleting objects from a pool I've noticed that deleting objects from a basic k=2 m=1 erasure pool is much much slower than deleting a similar number of objects from a replicated size 3 pool (so the same number of files to be deleted). It looked like the ec pool object deletion was almost 20x slower. Is there a lot more work to be done to delete an ec pool object? -- Tom -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- ow...@vger.kernel.org] On Behalf Of Dalek, Piotr Sent: Wednesday, June 24, 2015 11:56 AM To: ceph-devel Subject: Re: deleting objects from a pool -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- ow...@vger.kernel.org] On Behalf Of Deneau, Tom Sent: Wednesday, June 24, 2015 6:44 PM I have benchmarking situations where I want to leave a pool around but delete a lot of objects from the pool. Is there any really fast way to do that? I noticed rados rmpool is fast but I don't want to remove the pool. I have been spawning multiple threads, each deleting a subset of the objects (which I believe is what rados bench write does) but even that can be very slow. For now, apart from "rados -p cleanup" (which doesn't purge the pool, but merely removes objects written during last benchmark run), the only option is by brute force: for i in $(rados -p ls); do (rados -p rm $i &>/dev/null &); done; There's no "purge pool" command in rados -- not yet, at least. I was thinking about one, but never really had time to implement one. With best regards / Pozdrawiam Piotr Dałek -- 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 -- 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: Any concern about Ceph on CentOS
Hi Dieter, Thanks a lot for the information. Could I learn more about your use case ? Would you care performance ? And may I know why you want CentOS+ Custom kernel ? I thought people use CentOS for stability concern but if using CentOS + Custom Kernel, why don't you just use Ubuntu or Fedora(although Fedora is usually too aggressive). Xiaoxi -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Kasper Dieter Sent: Wednesday, July 17, 2013 2:17 PM To: Chen, Xiaoxi Cc: ceph-devel@vger.kernel.org; ceph-us...@ceph.com Subject: Re: Any concern about Ceph on CentOS Hi Xiaoxi, we are really running Ceph on CentOS-6.4 (6 server nodes, 3 client nodes, 160 OSDs). We put a 3.8.13 Kernel on top and installed the ceph-0.61.4 cluster with mkcephfs, because ceph-deploy seems to be still very buggy and has big dependencies to the newest python. ceph.ko rbd.ko and ceph-fuse are running fast, well and stable (so far ;-) ). Cheers, -Dieter On Wed, Jul 17, 2013 at 03:18:22AM +0200, Chen, Xiaoxi wrote: > Hi list, >I would like to ask if anyone really run Ceph on CentOS/RHEL? >Since the kernel version for Cent/RHEL is much older than that of Ubuntu, >I am thinking about whether we have some known performance/functionality > issue? >Thanks for everyone could share your insight for Ceph+CentOS. > > > Xiaoxi > -- > 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: [PATCH] osd/erasurecode: Fix memory leak in jerasure_matrix_to_bitmatrix()
Hi !
In this case, it should be more efficient to do the NULL check before the
talloc (you'll save the free operation and a useless memory allocation)
Cheers,
Philippe
-Message d'origine-
De : ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org]
De la part de Loic Dachary
Envoyé : samedi 2 novembre 2013 10:17
À : Sage Weil; Xing Lin
Cc : ceph-devel@vger.kernel.org
Objet : Re: [PATCH] osd/erasurecode: Fix memory leak in
jerasure_matrix_to_bitmatrix()
On 02/11/2013 08:03, Sage Weil wrote:
> Hi!
>
> On Sat, 2 Nov 2013, Xing Lin wrote:
>> Free allocated memory before return because of NULL input
>>
>> Signed-off-by: Xing Lin
>> ---
>> src/osd/ErasureCodePluginJerasure/jerasure.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/osd/ErasureCodePluginJerasure/jerasure.c
>> b/src/osd/ErasureCodePluginJerasure/jerasure.c
>> index 9efae02..1bb4b1d 100755
>> --- a/src/osd/ErasureCodePluginJerasure/jerasure.c
>> +++ b/src/osd/ErasureCodePluginJerasure/jerasure.c
>> @@ -276,7 +276,10 @@ int *jerasure_matrix_to_bitmatrix(int k, int m, int w,
>> int *matrix)
>>int rowelts, rowindex, colindex, elt, i, j, l, x;
>>
>>bitmatrix = talloc(int, k*m*w*w);
>> - if (matrix == NULL) { return NULL; }
>> + if (matrix == NULL) {
>> +free(bitmatrix);
>> +return NULL;
>> + }
>
> I have a feeling the author meant to say if (bitmatrix == NULL), since
> all the other talloc calls in this file tend to be followed by a NULL check?
Yes. Good catch Xing Lin :-)
Cheers
>
> sage
>
>
>>
>>rowelts = k * w;
>>rowindex = 0;
>> --
>> 1.8.3.4 (Apple Git-47)
>>
>> --
>> 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
>
--
Loïc Dachary, Artisan Logiciel Libre
--
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: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params
Thanks. let's try do this test on our setup. BTW, what workload you use here? -jiangang -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy Sent: Wednesday, October 08, 2014 5:51 PM To: Duan, Jiangang; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Hi Jiangang, I managed to get some data for you but it's for a 3 node cluster. I will try to get data for single node as well. Test config: - Cluster and rbd node config: -- "2x E5-2680 10C 2.8GHz 25M 8x 16GB RDIMM, dual rank x4 (128GB) Mellanox MT27500 40 Gigabit Ethernet LSI 9207 SAS HBA" 8 X 800 GB SSDs (Optimus Eco) per cluster node 3 cluster nodes + 3 rbd nodes Total storage ~ 19 TB We have total 24 OSDs running , each node has 8 OSDs/SSD Configured 3 pools with 528 PGs/pool and 6 RBDs/pool . Each RBD image size is ~230G. We have tried on 64K_RR_QD64 workload here. HT_ENABLE -- IOPS : 112500 Throughput (MB/S): 7012 Avg Resp.Time (m.sec):17 Max Resp.Time (m.sec): 3184 HT_DISABLE -- IOPS : 120864 Throughput (MB/S): 7530 Avg Resp.Time (m.sec):11 Max Resp.Time (m.sec): 1056 So, ~7% iop increase but response time decrease is ~35% which is real good. Thanks & Regards Somnath -Original Message- From: Duan, Jiangang [mailto:jiangang.d...@intel.com] Sent: Wednesday, October 08, 2014 1:03 PM To: Somnath Roy; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Sound good. Thanks. -jiangang -Original Message- From: Somnath Roy [mailto:somnath@sandisk.com] Sent: Wednesday, October 08, 2014 10:53 AM To: Duan, Jiangang; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Hi Jiangang, Give me a day or two, I will gather all the data and share with community. Thanks & Regards Somnath -Original Message- From: Duan, Jiangang [mailto:jiangang.d...@intel.com] Sent: Wednesday, October 08, 2014 10:47 AM To: Somnath Roy; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Can you guys share the w/ HT and w/o HT data? I want to take a look at that to understand why. -jiangang -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy Sent: Wednesday, October 08, 2014 10:38 AM To: Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Thanks Andres for sharing this. I will try those out. BTW, I am using Ubuntu 14.04 LTS and couldn't find any sysfs entry like 'cpufreq'.. root@stormeap-4:~# ll /sys/devices/system/cpu/cpu10/ cache/crash_notes driver/ microcode/online subsystem/topology/ cpuidle/ crash_notes_size firmware_node/node0/power/ thermal_throttle/ uevent I am using Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz. Regards Somnath -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Andreas Bluemle Sent: Wednesday, October 08, 2014 9:33 AM To: ceph-devel@vger.kernel.org Subject: Re: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Hi, as mentioned during today's meeting, here are the kernel boot parameters which I found to provide the basis for good performance results: processor.max_cstate=0 intel_idle.max_cstate=0 I understand these to basically turn off any power saving modes of the CPU; the CPU's we are using are like Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz At the BIOS level, we - turn off Hyperthraeding - turn off Turbo mode (in order ot not leave the specifications) - turn on frequency floor override We also assert that /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor is set to "performance" Using above we see a constant frequency at the maximum level allowed by the CPU (except Turbo mode). Best Regards Andreas Bluemle On Wed, 8 Oct 2014 02:51:21 +0200 Mark Nelson wrote: > Hi All, > > Just a remind that the weekly performance meeting is on Wednesdays at > 8AM PST. Same bat time, same bat channel! > > Etherpad URL: > http://pad.ceph.com/p/performance_weekly > > To join the Meeting: > https://bluejeans.com/268261044 > > To join via Browser: > https://bluejeans.com/268261044/browser > > To join with Lync: > https://bluejeans.com/268261044/lync > &
RE: Question about Transaction::get_data_alignment
Hi Sage,
I think I have make a draft of this patch, could you pls kindly take a
review at
https://github.com/xiaoxichen/ceph/commit/983a36be52d4ddd17133979c17b25e9e319a5dad
?
By "streamline the encode path for these messages", do you mean we can do
something like below so we can skip the initialize of some fields?
MOSDClientSubOp(ALL_ARGS_NEED_TO_SEND)
: Message(MSG_OSD_CLIENT_SUBOP, HEAD_VERSION, COMPAT_VERSION)
{
encode_payload(uint64_t features, ALL_ARGS_NEED_TO_SEND) ;
}
Xiaoxi
-Original Message-
From: ceph-devel-ow...@vger.kernel.org
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil
Sent: Friday, November 21, 2014 9:33 AM
To: Chen, Xiaoxi
Cc: jianpeng; ceph-devel@vger.kernel.org; Cook, Nigel
Subject: RE: Question about Transaction::get_data_alignment
On Fri, 21 Nov 2014, Chen, Xiaoxi wrote:
> Hi,
> I have cleanup the MOSDClientSubOP and changed the issue_op. The
> receive side is still wip. Sorry for the slow progress since blocked by a
> customer support case for some weeks.
> Here is the brunch to see if I goes on the right path.
>
> https://github.com/xiaoxichen/ceph/commit/621c2a7dc2bc9724e9d2106b52aa
> 9eedd2c793e8
Yep, this looks like the right direction!
Once the reply path is in place, I think there are some things we can do to
streamline the encode path for these messages (by, e.g., passing everything to
the constructor and encoding directly there instead of copying into member
variables and then encoding). Let's start with something simple first, though.
Thanks-
sage
>
> -Original Message-
> From: Sage Weil [mailto:s...@newdream.net]
> Sent: Friday, November 21, 2014 1:30 AM
> To: Chen, Xiaoxi
> Cc: jianpeng; ceph-devel@vger.kernel.org; Cook, Nigel
> Subject: RE: Question about Transaction::get_data_alignment
>
> Hi Xiaoxi,
>
> Just wanted to touch base and see how things are going here. I have some
> time to spend on this and the related efforts so please let me know if you
> have any questions or if you have some work-in-progress code I can help
> review.
>
> Thanks!
> sage
>
>
> On Thu, 6 Nov 2014, Chen, Xiaoxi wrote:
>
> > Hi Sage,
> > As discussed with Jianpeng, I would like to take this job.
> > Thank you.
> > Xiaoxi
> >
> > -Original Message-
> > From: ceph-devel-ow...@vger.kernel.org
> > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil
> > Sent: Wednesday, November 5, 2014 9:20 PM
> > To: jianpeng
> > Cc: ceph-devel@vger.kernel.org
> > Subject: Re: Question about Transaction::get_data_alignment
> >
> > On Wed, 5 Nov 2014, jianpeng wrote:
> > > Dong Yuan unitedstack.com> writes:
> > >
> > > >
> > > > Hi Sage,
> > > >
> > > > I am now working with the BP osd: update Transaction encoding,
> > > > but the Transaction::get_data_alignment make me confused.
> > > >
> > > > This method give the alignment which is used by FileJournal to
> > > > do better buffer build. It calculate the alignment by
> > > > largest_data_off and get_data_offset() while the first is an
> > > > offset of some object and the second is an offset of the
> > > > transaction encode result. I am not sure there is any reason to do
> > > > calculation between them.
> > > >
> > > > The code works fine, probably because any result is fine for
> > > > Transaction::get_data_alignment, while
> > > > FileJournal::prepare_single_write can use any alignment value to
> > > > build logical bufferlist.
> > > >
> > > > Can you give me some explanation? Thank you.
> > > >
> > >
> > > Hi, i send a pull request to reduce the memcopy cause by unalignment.
> > > https://github.com/ceph/ceph/pull/2803
> > > I think get_data_offset() should not care largest_data_off.
> >
> > I finally got to testing this and it looks good. Pulled the patches
> > manually into master. Sorry it took so long!
> >
> > For the last two MOSDSubOp, I think those changes should be done as
> > part of this ticket
> >
> > http://tracker.ceph.com/issues/9961
> >
> > which will replace the common client replication op to use a fresh message
> > type that is properly optimized. Jianpeng, is this something you might be
> > interested in working on? We talked with Haomai about it during
RE: deleting objects from a pool
Igor -- Good command to know, but this is still very slow on an erasure pool. For example, on my cluster it took 10 seconds with rados bench to write 10,000 40K size objects to an ecpool. And it took almost 6 minutes to delete them using the command below. -- Tom > -Original Message- > From: Podoski, Igor [mailto:igor.podo...@ts.fujitsu.com] > Sent: Thursday, June 25, 2015 1:06 AM > To: Deneau, Tom; Dałek, Piotr; ceph-devel > Subject: RE: deleting objects from a pool > > Hi, > > It appears, that cleanup can be used as a purge: > > rados -p cleanup --prefix "" > > Regards, > Igor. > > > -Original Message- > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > ow...@vger.kernel.org] On Behalf Of Deneau, Tom > Sent: Wednesday, June 24, 2015 10:22 PM > To: Dałek, Piotr; ceph-devel > Subject: RE: deleting objects from a pool > > I've noticed that deleting objects from a basic k=2 m=1 erasure pool is much > much slower than deleting a similar number of objects from a replicated size > 3 pool (so the same number of files to be deleted). It looked like the ec > pool object deletion was almost 20x slower. Is there a lot more work to be > done to delete an ec pool object? > > -- Tom > > > > > -Original Message- > > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > > ow...@vger.kernel.org] On Behalf Of Dalek, Piotr > > Sent: Wednesday, June 24, 2015 11:56 AM > > To: ceph-devel > > Subject: Re: deleting objects from a pool > > > > > -Original Message- > > > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > > > ow...@vger.kernel.org] On Behalf Of Deneau, Tom > > > Sent: Wednesday, June 24, 2015 6:44 PM > > > > > > I have benchmarking situations where I want to leave a pool around > > > but delete a lot of objects from the pool. Is there any really fast > > > way to do > > that? > > > I noticed rados rmpool is fast but I don't want to remove the pool. > > > > > > I have been spawning multiple threads, each deleting a subset of the > > objects > > > (which I believe is what rados bench write does) but even that can > > > be very slow. > > > > For now, apart from "rados -p cleanup" (which doesn't purge > > the pool, but merely removes objects written during last benchmark > > run), the only option is by brute force: > > > > for i in $(rados -p ls); do (rados -p rm $i > > &>/dev/null &); done; > > > > There's no "purge pool" command in rados -- not yet, at least. I was > > thinking about one, but never really had time to implement one. > > > > With best regards / Pozdrawiam > > Piotr Dałek > > -- > > 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: 03/18/2015 Weekly Ceph Performance Meeting IS ON!
Sorry to have missed most of the meeting -- is it possible to get a recording? Thanks, Stephen -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Mark Nelson Sent: Wednesday, March 18, 2015 6:12 AM To: ceph-devel@vger.kernel.org Subject: 03/18/2015 Weekly Ceph Performance Meeting IS ON! 8AM PST as usual! Please add an agenda item if there is something you want to talk about! Here's the links: Etherpad URL: http://pad.ceph.com/p/performance_weekly To join the Meeting: https://bluejeans.com/268261044 To join via Browser: https://bluejeans.com/268261044/browser To join with Lync: https://bluejeans.com/268261044/lync To join via Room System: Video Conferencing System: bjn.vc -or- 199.48.152.152 Meeting ID: 268261044 To join via Phone: 1) Dial: +1 408 740 7256 +1 888 240 2560(US Toll Free) +1 408 317 9253(Alternate Number) (see all numbers - http://bluejeans.com/numbers) 2) Enter Conference ID: 268261044 Mark -- 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: keyvaluestore speed up?
2015-03-20 10:22 GMT+08:00 Shu, Xinxin : > I think rocksdb can support this configuration. > I do not find this option in rocksdb. If you know, can you provide this option to redirect the WAL file? Regards Ning Yao > Cheers, > xinxin > > -Original Message- > From: ceph-devel-ow...@vger.kernel.org > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Xinze Chi > Sent: Thursday, March 19, 2015 5:23 PM > To: Sage Weil; sj...@redhat.com; Haomai Wang; ceph-devel@vger.kernel.org > Subject: keyvaluestore speed up? > > hi, all: > > Currently at keyvaluestore, osd send sync > request(submit_transaction_sync) to filestore when it finishes a transaction. > But sata disk is not suitable for doing sync request. ssd disk is more > suitable. > > So I think whether we could separate leveldb *.log file with *.sst file > and move *.log to ssd disk, which is similar with journal file in ceph. > > But now, the original leveldb do not support to separate log file and sst > file. > > Wait for your comment. > > Thanks. > -- > 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: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params
As I mentioned, total workload is ~19 TB...Each RBD is ~230 GB and io_size = 64K.. -Original Message- From: Duan, Jiangang [mailto:jiangang.d...@intel.com] Sent: Friday, October 10, 2014 4:39 PM To: Somnath Roy; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Thanks. let's try do this test on our setup. BTW, what workload you use here? -jiangang -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy Sent: Wednesday, October 08, 2014 5:51 PM To: Duan, Jiangang; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Hi Jiangang, I managed to get some data for you but it's for a 3 node cluster. I will try to get data for single node as well. Test config: - Cluster and rbd node config: -- "2x E5-2680 10C 2.8GHz 25M 8x 16GB RDIMM, dual rank x4 (128GB) Mellanox MT27500 40 Gigabit Ethernet LSI 9207 SAS HBA" 8 X 800 GB SSDs (Optimus Eco) per cluster node 3 cluster nodes + 3 rbd nodes Total storage ~ 19 TB We have total 24 OSDs running , each node has 8 OSDs/SSD Configured 3 pools with 528 PGs/pool and 6 RBDs/pool . Each RBD image size is ~230G. We have tried on 64K_RR_QD64 workload here. HT_ENABLE -- IOPS : 112500 Throughput (MB/S): 7012 Avg Resp.Time (m.sec):17 Max Resp.Time (m.sec): 3184 HT_DISABLE -- IOPS : 120864 Throughput (MB/S): 7530 Avg Resp.Time (m.sec):11 Max Resp.Time (m.sec): 1056 So, ~7% iop increase but response time decrease is ~35% which is real good. Thanks & Regards Somnath -Original Message- From: Duan, Jiangang [mailto:jiangang.d...@intel.com] Sent: Wednesday, October 08, 2014 1:03 PM To: Somnath Roy; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Sound good. Thanks. -jiangang -Original Message- From: Somnath Roy [mailto:somnath@sandisk.com] Sent: Wednesday, October 08, 2014 10:53 AM To: Duan, Jiangang; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Hi Jiangang, Give me a day or two, I will gather all the data and share with community. Thanks & Regards Somnath -Original Message- From: Duan, Jiangang [mailto:jiangang.d...@intel.com] Sent: Wednesday, October 08, 2014 10:47 AM To: Somnath Roy; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Can you guys share the w/ HT and w/o HT data? I want to take a look at that to understand why. -jiangang -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy Sent: Wednesday, October 08, 2014 10:38 AM To: Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Thanks Andres for sharing this. I will try those out. BTW, I am using Ubuntu 14.04 LTS and couldn't find any sysfs entry like 'cpufreq'.. root@stormeap-4:~# ll /sys/devices/system/cpu/cpu10/ cache/crash_notes driver/ microcode/online subsystem/topology/ cpuidle/ crash_notes_size firmware_node/node0/power/ thermal_throttle/ uevent I am using Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz. Regards Somnath -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Andreas Bluemle Sent: Wednesday, October 08, 2014 9:33 AM To: ceph-devel@vger.kernel.org Subject: Re: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Hi, as mentioned during today's meeting, here are the kernel boot parameters which I found to provide the basis for good performance results: processor.max_cstate=0 intel_idle.max_cstate=0 I understand these to basically turn off any power saving modes of the CPU; the CPU's we are using are like Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz At the BIOS level, we - turn off Hyperthraeding - turn off Turbo mode (in order ot not leave the specifications) - turn on frequency floor override We also assert that /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor is set to "performance" Using above we see a constant frequency at the maximum level allowed by the CPU (except Turbo mode). Best Regards Andreas Bluemle On Wed, 8 Oct 2014 02:51:21 +0200 Mark Nelson wrote: > Hi All, > > Just a remind that the weekly performance meeting is on Wednesdays a
Re: rbd snap
On Fri, 23 Sep 2011, Martin Mailand wrote: > Hi, > that's great, and it is safe to start diffrent vms with diffrent snapshots of > the same image at the same time? Yeah. Just remember they're read-only... sage > > Best Regards, > Martin > > Sage Weil schrieb: > > On Fri, 23 Sep 2011, Martin Mailand wrote: > > > Hi, > > > is it possible to access snapshots without to rollback the head of the rbd > > > volumen? > > > Because I want to do a snapshot of a vm running via librbd and qemu, and > > > use > > > the snapshot to make a offsite backup of the vm. > > > > $ rbd export foo --snap=mysnap /path/to/foo.dump > > > > You can also map the snapshot via qemu with a string like > > rbd:rbd/foo@mysnap. > > > > sage > > > > > > > Best Regards, > > > Martin > > > > > > > > > Martin Mailand schrieb: > > > > Okay, with the btrfs patch and the right commandline snapshotting works > > > > like > > > > a charm. > > > > > > > > best regards, > > > > martin > > > > > > > > Josh Durgin schrieb: > > > > > On 09/16/2011 02:32 PM, Martin Mailand wrote: > > > > > > root@c-brick-001:~# rbd rm --snap=2011091601 test > > > > > > *** Caught signal (Segmentation fault) ** > > > > > > in thread 0x7f203d749740 > > > > > > ceph version 0.34 (commit:2f039eeeb745622b866d80feda7afa055e15f6d6) > > > > > > 1: rbd() [0x457062] > > > > > > 2: (()+0xfc60) [0x7f203ccf6c60] > > > > > > 3: (librbd::snap_set(librbd::ImageCtx*, char const*)+0x10) > > > > > > [0x7f203d32ecd0] > > > > > > 4: (main()+0x59f) [0x4518ff] > > > > > > 5: (__libc_start_main()+0xff) [0x7f203b6cdeff] > > > > > > 6: rbd() [0x44d569] > > > > > > Segmentation fault > > > > > I added a bug to the tracker for this > > > > > (http://tracker.newdream.net/issues/1545). It shouldn't crash the way > > > > > you > > > > > ran it, but if you're trying to remove a snapshot you need to use the > > > > > 'snap rm' command, i.e.: > > > > > $ rbd snap rm --snap=2011091601 test > > > > > -- > > > > > 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 > > -- 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] ceph: fix memory leak in async readpages
Thanks, Jeff!
Was there a workload that reliably triggered this case?
sage
On Mon, 24 Oct 2011, Jeff Wu wrote:
> Hi ,
>
> start_read() do twice "kfree(pages)",
>
>
> out_pages:
> ceph_release_page_vector(pages, nr_pages);
> kfree(pages);
>
>
> ceph_release_page_vector had kfree pages, continue to do kfree(pages),
> sometimes ,async read ,printk "BUG kmalloc-16: Object already
> free" ,then OOPS.
>
> Jeff Wu
>
> --
> void ceph_release_page_vector(struct page **pages, int num_pages)
> {
> int i;
>
> for (i = 0; i < num_pages; i++)
> __free_pages(pages[i], 0);
> kfree(pages);
> }
>
>
> $ git diff
> diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
> index 5ffee90..4144caf 100644
> --- a/fs/ceph/addr.c
> +++ b/fs/ceph/addr.c
> @@ -345,7 +345,6 @@ static int start_read(struct inode *inode, struct
> list_head *page_list, int max)
>
> out_pages:
> ceph_release_page_vector(pages, nr_pages);
> - kfree(pages);
> out:
> ceph_osdc_put_request(req);
> return ret;
>
>
> On Thu, 2011-09-29 at 03:16 +0800, Sage Weil wrote:
> > On Wed, 28 Sep 2011, Sage Weil wrote:
> > > I'll send this upstream with the other patches so it'll hopefully make
> > > 3.1...
> >
> > Er, not really.. this'll go upstream during the next merge window, along
> > with the readahead code. :)
> >
> > sage
> >
> >
> > >
> > > Thanks!
> > > sage
> > >
> > >
> > > On Wed, 28 Sep 2011, David Flynn wrote:
> > >
> > > > The finish_read callback introduced in 63c90314546c1cec1f220f6ab24ea
> > > > fails to release the page list allocated in start_read.
> > > > ---
> > > > fs/ceph/addr.c |1 +
> > > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
> > > > index e06a322..4144caf 100644
> > > > --- a/fs/ceph/addr.c
> > > > +++ b/fs/ceph/addr.c
> > > > @@ -261,6 +261,7 @@ static void finish_read(struct ceph_osd_request
> > > > *req, struct ceph_msg *msg)
> > > > unlock_page(page);
> > > > page_cache_release(page);
> > > > }
> > > > + kfree(req->r_pages);
> > > > }
> > > >
> > > > /*
> > > > --
> > > > 1.7.4.1
> > > > --
> > > > 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
>
>
--
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: Slow request warnings on 0.48
That's odd — there isn't too much that went into the OSD between 0.47 and 0.48 that I can think of, and most of that only impact OSDs when they go through bootup. What does ceph -s display — are all the PGs healthy? -Greg On Wednesday, July 4, 2012 at 9:58 AM, Alexandre DERUMIER wrote: > Hi, I see same messages here after upgrade to 0.48. > > with random write benchmark. > > I have more lags than before with 0.47 (but disks are at 100% usage, so can't > tell if it's normal or not) > > > - Mail original - > > De: "David Blundell" (mailto:david.blund...@100percentit.com)> > À: ceph-devel@vger.kernel.org (mailto:ceph-devel@vger.kernel.org) > Envoyé: Mercredi 4 Juillet 2012 18:53:02 > Objet: Slow request warnings on 0.48 > > I have three servers running mon and osd using Ubuntu 12.04 that I have been > testing with RADOS storing RBD KVM instances > > 0.47.3 worked extremely well (once I got over a few btrfs issues). The same > servers running 0.48 give a large number of "[WRN] slow request" messages > whenever I generate a lot of random IO in the KVM instances using iozone. The > slow responses eventually leads to disk timeouts on the KVM instances. > > I have erased the osds and recreated on new btrfs volumes with the same > result. > > I have also tried switching to xfs using mkfs.xfs -n size=64k with noatime, > inode64,delaylog,logbufs=8,logbsize=256k > > Xfs gives the same result - the iozone tests run fine until the random IO > starts and then there are lots of slow request warnings. > > Does anyone have any ideas about the best place to start troubleshooting / > debugging? > > Thanks, > > David > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > (mailto:majord...@vger.kernel.org) > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > > -- > > > > > Alexandre D e rumier > > Ingénieur Systèmes et Réseaux > > > Fixe : 03 20 68 88 85 > > Fax : 03 20 68 90 88 > > > 45 Bvd du Général Leclerc 59100 Roubaix > 12 rue Marivaux 75002 Paris > > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > (mailto: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: RGW: Refusing FastCGI request with empty CONTENT_LENGTH ? Why ?
This one afaik: https://github.com/carsonoid/ceph/commit/96896eb092c3b4e0760e56d5228ef0d604951a12 Mark On 04/02/2013 10:27 AM, Sage Weil wrote: On Tue, 2 Apr 2013, Sylvain Munaut wrote: Hi, Replying to myself So that means if there is a CONTENT_LENGTH field in the environment but it's empty, then the request is just refused. This is fixed in master but wasn't backported to the bobtail branch, which is how I missed it ... Which commit? We can probably backport it.. s Sorry for the noise. Cheers, Sylvain -- 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: Anyone in NYC next week?
Just signed up, looking forward to it. On Thu, Jul 25, 2013 at 5:18 PM, Travis Rhoden wrote: > I'm already signed up. Looking forward to it! > > - Travis > > On Thu, Jul 25, 2013 at 12:19 AM, Sage Weil wrote: >> I'm going to be in NYC next week at our first Ceph Day of the summer. If >> you're in town and want to hear more about what we're doing, you should >> join us! >> >> http://www.inktank.com/CEPHdays/ >> >> 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 > -- > 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
[Cluster-devel] [PATCH V10 15/19] block: always define BIO_MAX_PAGES as 256
Now multi-page bvec can cover CONFIG_THP_SWAP, so we don't need to increase BIO_MAX_PAGES for it. Cc: Dave Chinner Cc: Kent Overstreet Cc: Mike Snitzer Cc: dm-de...@redhat.com Cc: Alexander Viro Cc: linux-fsde...@vger.kernel.org Cc: Shaohua Li Cc: linux-r...@vger.kernel.org Cc: linux-er...@lists.ozlabs.org Cc: David Sterba Cc: linux-bt...@vger.kernel.org Cc: Darrick J. Wong Cc: linux-...@vger.kernel.org Cc: Gao Xiang Cc: Christoph Hellwig Cc: Theodore Ts'o Cc: linux-e...@vger.kernel.org Cc: Coly Li Cc: linux-bca...@vger.kernel.org Cc: Boaz Harrosh Cc: Bob Peterson Cc: cluster-devel@redhat.com Signed-off-by: Ming Lei --- include/linux/bio.h | 8 1 file changed, 8 deletions(-) diff --git a/include/linux/bio.h b/include/linux/bio.h index 5040e9a2eb09..277921ad42e7 100644 --- a/include/linux/bio.h +++ b/include/linux/bio.h @@ -34,15 +34,7 @@ #define BIO_BUG_ON #endif -#ifdef CONFIG_THP_SWAP -#if HPAGE_PMD_NR > 256 -#define BIO_MAX_PAGES HPAGE_PMD_NR -#else #define BIO_MAX_PAGES 256 -#endif -#else -#define BIO_MAX_PAGES 256 -#endif #define bio_prio(bio) (bio)->bi_ioprio #define bio_set_prio(bio, prio)((bio)->bi_ioprio = prio) -- 2.9.5
Re: [Cluster-devel] [PATCH V10 19/19] block: kill BLK_MQ_F_SG_MERGE
On Thu, Nov 15, 2018 at 04:53:06PM +0800, Ming Lei wrote: > QUEUE_FLAG_NO_SG_MERGE has been killed, so kill BLK_MQ_F_SG_MERGE too. > > Cc: Dave Chinner > Cc: Kent Overstreet > Cc: Mike Snitzer > Cc: dm-de...@redhat.com > Cc: Alexander Viro > Cc: linux-fsde...@vger.kernel.org > Cc: Shaohua Li > Cc: linux-r...@vger.kernel.org > Cc: linux-er...@lists.ozlabs.org > Cc: David Sterba > Cc: linux-bt...@vger.kernel.org > Cc: Darrick J. Wong > Cc: linux-...@vger.kernel.org > Cc: Gao Xiang > Cc: Christoph Hellwig > Cc: Theodore Ts'o > Cc: linux-e...@vger.kernel.org > Cc: Coly Li > Cc: linux-bca...@vger.kernel.org > Cc: Boaz Harrosh > Cc: Bob Peterson > Cc: cluster-devel@redhat.com Reviewed-by: Omar Sandoval > Signed-off-by: Ming Lei > --- > block/blk-mq-debugfs.c | 1 - > drivers/block/loop.c | 2 +- > drivers/block/nbd.c | 2 +- > drivers/block/rbd.c | 2 +- > drivers/block/skd_main.c | 1 - > drivers/block/xen-blkfront.c | 2 +- > drivers/md/dm-rq.c | 2 +- > drivers/mmc/core/queue.c | 3 +-- > drivers/scsi/scsi_lib.c | 2 +- > include/linux/blk-mq.h | 1 - > 10 files changed, 7 insertions(+), 11 deletions(-) [snip]
RE: Cache tiering slow request issue: currently waiting for rw locks
I made some comments based on your comments of the pull request https://github.com/ceph/ceph/pull/2374. Can you take a look? Thx. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Wang, Zhiqiang Sent: Tuesday, September 2, 2014 2:54 PM To: Sage Weil Cc: 'ceph-devel@vger.kernel.org' Subject: RE: Cache tiering slow request issue: currently waiting for rw locks Tried the pull request, checking the object is blocked or not doesn't work. Actually this check is already done in function agent_work. I tried to make a fix to add a field/flag to the object context. This is not a good idea for the following reasons: 1) If making this filed/flag to be a persistent one, when resetting/clearing this flag, we need to persist it. This is not good for read request. 2) If making this field/flag not to be a persistent one, when the object context is removed from the cache ' object_contexts', this field/flag is removed as well. This object is removed in the later evicting. The same issue still exists. So, I came up with a fix to add a set in the class ReplicatedPG to hold all the promoting objects. This fix is at https://github.com/ceph/ceph/pull/2374. It is tested and works well. Pls review and comment, thx. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Wang, Zhiqiang Sent: Monday, September 1, 2014 9:33 AM To: Sage Weil Cc: 'ceph-devel@vger.kernel.org' Subject: RE: Cache tiering slow request issue: currently waiting for rw locks I don't think the object context is blocked at that time. It is un-blocked after the copying of data from base tier. It doesn't address the problem here. Anyway, I'll try it and see. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil Sent: Saturday, August 30, 2014 10:29 AM To: Wang, Zhiqiang Cc: 'ceph-devel@vger.kernel.org' Subject: Re: Cache tiering slow request issue: currently waiting for rw locks Hi, Can you take a look at https://github.com/ceph/ceph/pull/2363 and see if that addresses the behavior you saw? Thanks! sage On Fri, 29 Aug 2014, Sage Weil wrote: > Hi, > > I've opened http://tracker.ceph.com/issues/9285 to track this. > > I think you're right--we need a check in agent_maybe_evict() that will > skip objects that are being promoted. I suspect a flag on the > ObjectContext is enough? > > sage > > > On Fri, 29 Aug 2014, Wang, Zhiqiang wrote: > > > Hi all, > > > > I've ran into this slow request issue some time ago. The problem is like > > this: when running with cache tieing, there are 'slow request' warning > > messages in the log file like below. > > > > 2014-08-29 10:18:24.669763 7f9b20f1b700 0 log [WRN] : 1 slow > > requests, 1 included below; oldest blocked for > 30.996595 secs > > 2014-08-29 10:18:24.669768 7f9b20f1b700 0 log [WRN] : slow request > > 30.996595 seconds old, received at 2014-08-29 10:17:53.673142: > > osd_op(client.114176.0:144919 rb.0.17f56.6b8b4567.0935 > > [sparse-read 3440640~4096] 45.cf45084b ack+read e26168) v4 currently > > waiting for rw locks > > > > Recently I made some changes to the log, captured this problem, and finally > > figured out its root cause. You can check the attachment for the logs. > > > > Here is the root cause: > > There is a cache miss when doing read. During promotion, after copying the > > data from base tier osd, the cache tier primary osd replicates the data to > > other cache tier osds. Some times this takes quite a long time. During this > > period of time, the promoted object may be evicted because the cache tier > > is full. When the primary osd finally gets the replication response and > > restarts the original read request, it doesn't find the object in the cache > > tier, and do promotion again. This loops for several times, and we'll see > > the 'slow request' in the logs. Theoretically, this could loops forever, > > and the request from the client would never be finished. > > > > There is a simple fix for this: > > Add a field in the object state, indicating the status of the promotion. > > It's set to true after the copy of data from base tier and before the > > replication. It's reset to false after the replication and the original > > client request starts to execute. Evicting is not allowed when this field > > is true. > > > > What do you think? > > > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" > in the
Re: wip-auth
Hi Stephen, Does this explain the results you were seeing earlier with the memstore testing? Mark On 01/26/2015 12:00 PM, Blinick, Stephen L wrote: Good to know, I was wondering why the spec file defaulted to lib-nss.. the dpkg-build for debian packages just uses whatever configuration you had built, and I believe that will use libcryptopp if the dependency is installed on the build machine (last I looked). I forgot to mention the numbers below were based on v.91. Thanks, Stephen -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil Sent: Monday, January 26, 2015 10:24 AM To: Blinick, Stephen L Cc: andreas.blue...@itxperts.de; ceph-devel@vger.kernel.org Subject: RE: wip-auth On Mon, 26 Jan 2015, Blinick, Stephen L wrote: I noticed that the spec file for building RPM's defaults to building with libnss, instead of libcrypto++. Since the measurements I'd done so far were from those RPM's I rebuilt with libcrypto++.. so FWIW here is the difference between those two on my system, memstore backend with a single OSD, and single client. Dual socket Xeon E5 2620v3, 64GB Memory, RHEL7 Kernel: 3.10.0-123.13.2.el7 100% 4K Writes, 1xOSD w/ Rados Bench libnss |Cryptopp # QDIOPSLatency(ms) | IOPSLatency(ms) IOPS Improvement % 16 14432.571.11| 18896.600.8530.93% 100% 4K Reads, 1xOSD w/ Rados Bench libnss | Cryptopp # QD IOPS Latency(ms) | IOPS Latency(ms) IOPS Improvement % 16 19532.53 0.82 | 25708.70 0.62 31.62% Yikes, 30%! I think this definitely worth some effort. We switched to libnss because it has the weird government certfiications that everyone wants and is more prevalent. crypto++ is also not packaged for Red Hat distros at all (presumably for that reason). I suspect that most of the overhead is in the encryption context setup and can be avoided with a bit of effort.. sage Thanks, Stephen -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil Sent: Thursday, January 22, 2015 4:56 PM To: andreas.blue...@itxperts.de Cc: ceph-devel@vger.kernel.org Subject: wip-auth Hi Andreas, I took a look at the wip-auth I mentioned in the security call last week... and the patch didn't work at all. Sorry if you wasted any time trying it. Anyway, I fixed it up so that it actually worked and made one other optimization. It would be great to hear what latencies you measure with the changes in place. Also, it might be worth trying --with-cryptopp (or --with-nss if you built cryptopp by default) to see if there is a difference. There is a ton of boilerplate setting up encryption contexts and key structures and so on that I suspect could be cached (perhaps stashed in the CryptoKey struct?) with a bit of effort. See https://github.com/ceph/ceph/blob/master/src/auth/Crypto.cc#L99-L213 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 -- 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: OSD crashed today in os/JournalingObjectStore.cc
Hi, here a new dump / crash: https://www.dropbox.com/s/1qhg0dd0fv17q10/ceph-osd.54.log.gz Stefan Am 06.12.2012 00:36, schrieb Sage Weil: On Wed, 5 Dec 2012, Stefan Priebe - Profihost AG wrote: There was a dump in the attached log. The stack trace is there, but with 'debug journal = 0/20' in your conf it will also dump all of the journal logging activity leading up to that point. Can you reproduce with that enabled? That should tell me why op < commited_seq. Thanks! sage Stefan Am 05.12.2012 um 15:41 schrieb Sage Weil : On Wed, 5 Dec 2012, Stefan Priebe - Profihost AG wrote: Hello list, i updated to latest next from today and then after 20 minutes an OSD was crashing in os/JournalingObjectStore.cc. Attached is the log. Hmm, this is perplexing. It might just be a bad assert, but I can't see how it could happen. Any chance you can reproduce with debug journal = 0/10 in the [osd] section? That will give us a dump if it fails the assert. Thanks! s -- 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: Random blocks when accessing rbd images
In master, 061e7619aacf60a828e0ce84a108d5a0bea247c6 may fix the problem. If not, 5274e88d2cb8c0449a4ecd1ff0cf8bb0af2cfc97 includes some asserts that may give us a clue as to how this is happening. -Sam On Fri, Dec 16, 2011 at 8:17 AM, Wido den Hollander wrote: > Hi, > > > On 12/15/2011 05:44 PM, Martin Mailand wrote: >> >> Hi, >> at least there is a patch that should have fixed it. >> >> http://marc.info/?l=ceph-devel&m=131955913203561&w=2 >> > > I'm still seeing this one: > > 2011-12-16 17:14:53.638722 pg v1170309: 7808 pgs: 7807 active+clean, 1 > active+clean+scrubbing; 15279 MB data, 47262 MB used, 73838 GB / 74520 GB > avail > > In this case PG "2.688" is in scrubbing state and is staying that way. > > I'm running v0.39, not the latest master. > > Any suggestions to trace this one down? > > Wido > > >> Am 15.12.2011 17:38, schrieb Martin Mailand: >>> >>> Hi Wido, >>> but wasn't that fixed a few weeks ago? >>> >>> -martin >>> >>> Am 15.12.2011 17:33, schrieb Wido den Hollander: >>>> >>>> Yes, from what I've seen it will block indefinitely until you restart >>>> one of the OSDs who are member of the PG. >>>> >>>> Wido >>> >>> >>> -- >>> 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: git repository is gone
Sorry guys, it happened just about exactly 10 minutes ago and I think Sage hasn't gotten around to making an announcement or updating the website. We were going to do it at the end of the day but then realized that some of our testing infrastructure was going to break and we wanted to be working when it happened... Since you bring it up a little more notification probably would have been good, but please be gentle. We're trying to remove any company branding. :) On Friday, March 2, 2012 at 11:09 AM, Dirk Meister wrote: > Hello, > > it looks like that the NewDreamNetwork github organization was renamed > to ceph. So the new repository is https://github.com/ceph/ceph.git. > > See also: https://github.com/ceph/ceph > > I was also a bit surprised. There was no notification on the mailing > or have I missed something? > > Best regards, > Dirk > > On Fri, Mar 2, 2012 at 8:06 PM, Laszlo Boszormenyi (mailto:g...@debian.hu)> wrote: > > Hi, > > > > I've realized that: > > git/ceph $ git pull > > fatal: The remote end hung up unexpectedly > > > > Which is due to https://github.com/NewDreamNetwork/ceph being 404. > > Is the repository moving to somewhere else? The homepage still reference > > this address. > > > > Laszlo/GCS > > > > -- > > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > > the body of a message to majord...@vger.kernel.org > > (mailto: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 > (mailto: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: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction?
Huh..It seems the op_t is already copied in generate_subop() -> ::encode(*op_t, wr->get_data());...So, this shouldn't be an issue.. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy Sent: Sunday, November 01, 2015 8:59 AM To: Sage Weil; 池信泽 Cc: Ning Yao; ceph-devel@vger.kernel.org Subject: RE: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction? Sage, Is it possible that we can't reuse the op_t because it could be still there in the messenger queue before calling parent->log_operation() ? Thanks & Regards Somnath -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil Sent: Sunday, November 01, 2015 6:47 AM To: 池信泽 Cc: Ning Yao; ceph-devel@vger.kernel.org Subject: Re: why we use two ObjectStore::Transaction in ReplicatedBackend::submit_transaction? On Sun, 1 Nov 2015, Sage Weil wrote: > On Sun, 1 Nov 2015, ??? wrote: > > Yes, I think so. > > keeping them separate and pass them to > > ObjectStore::queue_transactions() would increase the time on > > transaction encode process and exhaust more cpu. > > > > The transaction::append holds 0.8% cpu on my environment. > > The transaction encoding is also really a bottleneck which process > > holds 1.8% cpu on my environment. > > Where is the append() caller you're looking at? I'm not seeing it. Oh, I see: https://github.com/ceph/ceph/pull/6439 This makes sense to me. 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 ㈤旃??迆??瑬+-遍荻w疄藳笔鈓??^介b炟^n噐■?侂h櫒璀?Ⅷ 瓽珴閔?(殠娸"濟?m?飦赇z罐枈帼f＂穐殘坢
RE: severe librbd performance degradation in Giant
Same question as Somnath, some customer of us not feeling that comfortable with cache, they still have some consistent concern. -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy Sent: Thursday, September 18, 2014 2:25 PM To: Sage Weil Cc: Haomai Wang; Josh Durgin; ceph-devel@vger.kernel.org Subject: RE: severe librbd performance degradation in Giant Sage, Any reason why the cache is by default enabled in Giant ? Regarding profiling, I will try if I can run Vtune/mutrace on this. Thanks & Regards Somnath -Original Message- From: Sage Weil [mailto:sw...@redhat.com] Sent: Wednesday, September 17, 2014 8:53 PM To: Somnath Roy Cc: Haomai Wang; Josh Durgin; ceph-devel@vger.kernel.org Subject: RE: severe librbd performance degradation in Giant On Thu, 18 Sep 2014, Somnath Roy wrote: > Yes Haomai... I would love to what a profiler says about the matter. There is going to be some overhead on the client associated with the cache for a random io workload, but 10x is a problem! sage > > -Original Message- > From: Haomai Wang [mailto:haomaiw...@gmail.com] > Sent: Wednesday, September 17, 2014 7:28 PM > To: Somnath Roy > Cc: Sage Weil; Josh Durgin; ceph-devel@vger.kernel.org > Subject: Re: severe librbd performance degradation in Giant > > According http://tracker.ceph.com/issues/9513, do you mean that rbd cache > will make 10x performance degradation for random read? > > On Thu, Sep 18, 2014 at 7:44 AM, Somnath Roy wrote: > > Josh/Sage, > > I should mention that even after turning off rbd cache I am getting ~20% > > degradation over Firefly. > > > > Thanks & Regards > > Somnath > > > > -Original Message- > > From: Somnath Roy > > Sent: Wednesday, September 17, 2014 2:44 PM > > To: Sage Weil > > Cc: Josh Durgin; ceph-devel@vger.kernel.org > > Subject: RE: severe librbd performance degradation in Giant > > > > Created a tracker for this. > > > > http://tracker.ceph.com/issues/9513 > > > > Thanks & Regards > > Somnath > > > > -Original Message- > > From: ceph-devel-ow...@vger.kernel.org > > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy > > Sent: Wednesday, September 17, 2014 2:39 PM > > To: Sage Weil > > Cc: Josh Durgin; ceph-devel@vger.kernel.org > > Subject: RE: severe librbd performance degradation in Giant > > > > Sage, > > It's a 4K random read. > > > > Thanks & Regards > > Somnath > > > > -Original Message- > > From: Sage Weil [mailto:sw...@redhat.com] > > Sent: Wednesday, September 17, 2014 2:36 PM > > To: Somnath Roy > > Cc: Josh Durgin; ceph-devel@vger.kernel.org > > Subject: RE: severe librbd performance degradation in Giant > > > > What was the io pattern? Sequential or random? For random a slowdown > > makes sense (tho maybe not 10x!) but not for sequentail > > > > s > > > > On Wed, 17 Sep 2014, Somnath Roy wrote: > > > >> I set the following in the client side /etc/ceph/ceph.conf where I am > >> running fio rbd. > >> > >> rbd_cache_writethrough_until_flush = false > >> > >> But, no difference. BTW, I am doing Random read, not write. Still this > >> setting applies ? > >> > >> Next, I tried to tweak the rbd_cache setting to false and I *got back* the > >> old performance. Now, it is similar to firefly throughput ! > >> > >> So, loks like rbd_cache=true was the culprit. > >> > >> Thanks Josh ! > >> > >> Regards > >> Somnath > >> > >> -Original Message- > >> From: Josh Durgin [mailto:josh.dur...@inktank.com] > >> Sent: Wednesday, September 17, 2014 2:20 PM > >> To: Somnath Roy; ceph-devel@vger.kernel.org > >> Subject: Re: severe librbd performance degradation in Giant > >> > >> On 09/17/2014 01:55 PM, Somnath Roy wrote: > >> > Hi Sage, > >> > We are experiencing severe librbd performance degradation in Giant over > >> > firefly release. Here is the experiment we did to isolate it as a librbd > >> > problem. > >> > > >> > 1. Single OSD is running latest Giant and client is running fio rbd on > >> > top of firefly based librbd/librados. For one client it is giving > >> > ~11-12K iops (4K RR). > >> > 2. Single OSD is running Giant and client is running fio rbd on top of > >> > Giant based librbd/librados. For one client it is givi
RE: [RFC] add rocksdb support
Currently ceph will get stable rocksdb from branch 3.0.fb of ceph/rocksdb , since PR https://github.com/ceph/rocksdb/pull/2 has not been merged , so if you use 'git submodule update --init' to get rocksdb submodule , It did not support autoconf/automake . -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sushma Gurram Sent: Saturday, June 14, 2014 2:52 AM To: Shu, Xinxin; Mark Nelson; Sage Weil Cc: ceph-devel@vger.kernel.org; Zhang, Jian Subject: RE: [RFC] add rocksdb support Hi Xinxin, I tried to compile the wip-rocksdb branch, but the src/rocksdb directory seems to be empty. Do I need toput autoconf/automake in this directory? It doesn't seem to have any other source files and compilation fails: os/RocksDBStore.cc:10:24: fatal error: rocksdb/db.h: No such file or directory compilation terminated. Thanks, Sushma -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Shu, Xinxin Sent: Monday, June 09, 2014 10:00 PM To: Mark Nelson; Sage Weil Cc: ceph-devel@vger.kernel.org; Zhang, Jian Subject: RE: [RFC] add rocksdb support Hi mark I have finished development of support of rocksdb submodule, a pull request for support of autoconf/automake for rocksdb has been created , you can find https://github.com/ceph/rocksdb/pull/2 , if this patch is ok , I will create a pull request for rocksdb submodule support , currently this patch can be found https://github.com/xinxinsh/ceph/tree/wip-rocksdb . -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Mark Nelson Sent: Tuesday, June 10, 2014 1:12 AM To: Shu, Xinxin; Sage Weil Cc: ceph-devel@vger.kernel.org; Zhang, Jian Subject: Re: [RFC] add rocksdb support Hi Xinxin, On 05/28/2014 05:05 AM, Shu, Xinxin wrote: > Hi sage , > I will add two configure options to --with-librocksdb-static and > --with-librocksdb , with --with-librocksdb-static option , ceph will compile > the code that get from ceph repository , with --with-librocksdb option , in > case of distro packages for rocksdb , ceph will not compile the rocksdb code > , will use pre-installed library. is that ok for you ? > > since current rocksdb does not support autoconf&automake , I will add > autoconf&automake support for rocksdb , but before that , i think we should > fork a stable branch (maybe 3.0) for ceph . I'm looking at testing out the rocksdb support as well, both for the OSD and for the monitor based on some issues we've been seeing lately. Any news on the 3.0 fork and autoconf/automake support in rocksdb? Thanks, Mark > > -Original Message- > From: Mark Nelson [mailto:mark.nel...@inktank.com] > Sent: Wednesday, May 21, 2014 9:06 PM > To: Shu, Xinxin; Sage Weil > Cc: ceph-devel@vger.kernel.org; Zhang, Jian > Subject: Re: [RFC] add rocksdb support > > On 05/21/2014 07:54 AM, Shu, Xinxin wrote: >> Hi, sage >> >> I will add rocksdb submodule into the makefile , currently we want to have >> fully performance tests on key-value db backend , both leveldb and rocksdb. >> Then optimize on rocksdb performance. > > I'm definitely interested in any performance tests you do here. Last winter > I started doing some fairly high level tests on raw > leveldb/hyperleveldb/raikleveldb. I'm very interested in what you see with > rocksdb as a backend. > >> >> -Original Message- >> From: Sage Weil [mailto:s...@inktank.com] >> Sent: Wednesday, May 21, 2014 9:19 AM >> To: Shu, Xinxin >> Cc: ceph-devel@vger.kernel.org >> Subject: Re: [RFC] add rocksdb support >> >> Hi Xinxin, >> >> I've pushed an updated wip-rocksdb to github/liewegas/ceph.git that includes >> the latest set of patches with the groundwork and your rocksdb patch. There >> is also a commit that adds rocksdb as a git submodule. I'm thinking that, >> since there aren't any distro packages for rocksdb at this point, this is >> going to be the easiest way to make this usable for people. >> >> If you can wire the submodule into the makefile, we can merge this in so >> that rocksdb support is in the ceph.com packages on ceph.com. I suspect >> that the distros will prefer to turns this off in favor of separate shared >> libs, but they can do this at their option if/when they include rocksdb in >> the distro. I think the key is just to have both --with-librockdb and >> --with-librocksdb-static (or similar) options so that you can either use the >> static or dynamically linked one. >> >> Has your group done further testing with rocksdb? Anything interesting to >> share? >
RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params
Hi Jiangang, Give me a day or two, I will gather all the data and share with community. Thanks & Regards Somnath -Original Message- From: Duan, Jiangang [mailto:jiangang.d...@intel.com] Sent: Wednesday, October 08, 2014 10:47 AM To: Somnath Roy; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Can you guys share the w/ HT and w/o HT data? I want to take a look at that to understand why. -jiangang -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy Sent: Wednesday, October 08, 2014 10:38 AM To: Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Thanks Andres for sharing this. I will try those out. BTW, I am using Ubuntu 14.04 LTS and couldn't find any sysfs entry like 'cpufreq'.. root@stormeap-4:~# ll /sys/devices/system/cpu/cpu10/ cache/crash_notes driver/ microcode/online subsystem/topology/ cpuidle/ crash_notes_size firmware_node/node0/power/ thermal_throttle/ uevent I am using Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz. Regards Somnath -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Andreas Bluemle Sent: Wednesday, October 08, 2014 9:33 AM To: ceph-devel@vger.kernel.org Subject: Re: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Hi, as mentioned during today's meeting, here are the kernel boot parameters which I found to provide the basis for good performance results: processor.max_cstate=0 intel_idle.max_cstate=0 I understand these to basically turn off any power saving modes of the CPU; the CPU's we are using are like Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz At the BIOS level, we - turn off Hyperthraeding - turn off Turbo mode (in order ot not leave the specifications) - turn on frequency floor override We also assert that /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor is set to "performance" Using above we see a constant frequency at the maximum level allowed by the CPU (except Turbo mode). Best Regards Andreas Bluemle On Wed, 8 Oct 2014 02:51:21 +0200 Mark Nelson wrote: > Hi All, > > Just a remind that the weekly performance meeting is on Wednesdays at > 8AM PST. Same bat time, same bat channel! > > Etherpad URL: > http://pad.ceph.com/p/performance_weekly > > To join the Meeting: > https://bluejeans.com/268261044 > > To join via Browser: > https://bluejeans.com/268261044/browser > > To join with Lync: > https://bluejeans.com/268261044/lync > > > To join via Room System: > Video Conferencing System: bjn.vc -or- 199.48.152.152 Meeting ID: > 268261044 > > To join via Phone: > 1) Dial: >+1 408 740 7256 >+1 888 240 2560(US Toll Free) >+1 408 317 9253(Alternate Number) >(see all numbers - http://bluejeans.com/numbers) > 2) Enter Conference ID: 268261044 > > Mark > -- > 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 > > -- Andreas Bluemle mailto:andreas.blue...@itxperts.de ITXperts GmbH http://www.itxperts.de Balanstrasse 73, Geb. 08Phone: (+49) 89 89044917 D-81541 Muenchen (Germany) Fax: (+49) 89 89044910 Company details: http://www.itxperts.de/imprint.htm -- 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 PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). -- 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: why we should use two Mutex in OSD ShardData?
I do not see any improvement by moving to single mutex. I just fell puzzle why we use two mutex. But I also do not see any improvement using two mutex in my environment. Thanks for your explanation. 2015-10-30 22:59 GMT+08:00 Somnath Roy : > > Hi xinze, > This is mainly for reducing lock contention on a single mutex. Conditional > wakeup on a mutex is expensive and that's why we wanted to make it separate > from the mutex protecting Sharddata priority queue and pg_for_processing map. > Are you seeing any improvement by moving to single mutex ? > > Thanks & Regards > Somnath > > -Original Message- > From: ceph-devel-ow...@vger.kernel.org > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of ??? > Sent: Friday, October 30, 2015 6:35 AM > To: ceph-devel@vger.kernel.org > Subject: why we should use two Mutex in OSD ShardData? > > hi, all: > >There are two Mutex in ShardData, one is sdata_lock and the other one is > sdata_op_ordering_lock. > > I wonder could we replace sdata_lock with sdata_op_ordering_lock? > > -- > Regards, > xinze > -- > 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 -- Regards, xinze -- 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: 11/19/2014 Weekly Ceph Performance Meeting IS ON!
Hi Mark, do you have the recording videos for this meeting? Regards, -yuan -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Mark Nelson Sent: Wednesday, November 19, 2014 10:49 AM To: ceph-devel@vger.kernel.org Subject: 11/19/2014 Weekly Ceph Performance Meeting IS ON! Hi All, 8AM PST as usual! Some lucky folks are out at Supercomputing 14 so the crowd might be a bit small this week. Feel free to add an agenda item if there is something you want to talk about! Here's the links: Etherpad URL: http://pad.ceph.com/p/performance_weekly To join the Meeting: https://bluejeans.com/268261044 To join via Browser: https://bluejeans.com/268261044/browser To join with Lync: https://bluejeans.com/268261044/lync To join via Room System: Video Conferencing System: bjn.vc -or- 199.48.152.152 Meeting ID: 268261044 To join via Phone: 1) Dial: +1 408 740 7256 +1 888 240 2560(US Toll Free) +1 408 317 9253(Alternate Number) (see all numbers - http://bluejeans.com/numbers) 2) Enter Conference ID: 268261044 Mark -- 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: fadvise status
> -Original Message- > From: ceph-devel-ow...@vger.kernel.org > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil > Sent: Thursday, December 4, 2014 2:57 PM > To: Ma, Jianpeng > Cc: sj...@redhat.com; ceph-devel@vger.kernel.org > Subject: fadvise status > > Hey, > > I'm getting caught up after being out most of last week. I see: > > https://github.com/ceph/ceph/pull/2964 > > client side librados and librbd changes. ready to go > > https://github.com/ceph/ceph/pull/2988 > > osd changes. look good, but needs a rebase (merge conflict?) and a > test. > I think at this point you should rebase everything into a single branch so > that > you can use the client-side stuff to add some simple functional tests in > ceph_test_rados_api_[a]io. Yes, merge into a single branch(met one conflict) and WIP on test case. > > https://github.com/ceph/ceph/pull/2817 > > I think this is superceded by the above changes.. can we just close it? > In my two pull requests don't contain this. I think they are independent. If you don't have disagreement on 2817. I think you can merge. Thanks Jianpeng > Thanks! > 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 -- 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
AW: who is using radosgw with civetweb?
Sage, we use apache as a filter for security and additional functionality reasons. I do like the idea, but we'd need some kind of interface to filter/modify/process requests. Best regards Axel Dunkel -Ursprüngliche Nachricht- Von: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] Im Auftrag von Sage Weil Gesendet: Mittwoch, 25. Februar 2015 20:32 An: ceph-us...@ceph.com; ceph-devel@vger.kernel.org Betreff: who is using radosgw with civetweb? Hey, We are considering switching to civetweb (the embedded/standalone rgw web server) as the primary supported RGW frontend instead of the current apache + mod-fastcgi or mod-proxy-fcgi approach. "Supported" here means both the primary platform the upstream development focuses on and what the downstream Red Hat product will officially support. How many people are using RGW standalone using the embedded civetweb server instead of apache? In production? At what scale? What version(s) (civetweb first appeared in firefly and we've backported most fixes). Have you seen any problems? Any other feedback? The hope is to (vastly) simplify deployment. Thanks! 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 -- 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: v2 aligned buffer changes for erasure codes
Hi Andreas, The per_chunk_alignment addresses a backward compatible change in the way they are calculated. The problem was that the initial calculation lead to oversized chunks. The long explanation is at https://github.com/ceph/ceph/commit/c7daaaf5e63d0bd1d444385e62611fe276f6ce29 Please let me know if you see something wrong :-) Cheers On 18/09/2014 14:34, Andreas Joachim Peters wrote: > Hi Janne/Loic, > there is more confusion atleast on my side ... > > I had now a look at the jerasure plug-in and I am now slightly confused why > you have two ways to return in get_alignment ... one is as I assume and > another one is "per_chunk_alignment" ... what should the function return Loic? > > Cheers Andreas. > ____ > From: ceph-devel-ow...@vger.kernel.org [ceph-devel-ow...@vger.kernel.org] on > behalf of Andreas Joachim Peters [andreas.joachim.pet...@cern.ch] > Sent: 18 September 2014 14:18 > To: Janne Grunau; ceph-devel@vger.kernel.org > Subject: RE: v2 aligned buffer changes for erasure codes > > Hi Janne, > => (src/erasure-code/isa/README claims it needs 16*k byte aligned buffers > > I should update the README since it is misleading ... it should say 8*k or > 16*k byte aligned chunk size depending on the compiler/platform used, it is > not the alignment of the allocated buffer addresses.The get_alignment in the > plug-in function is used to compute the chunk size for the encoding (as I > said not the start address alignment). > > If you pass k buffers for decoding each buffer should be aligned at least to > 16 or as you pointed out better 32 bytes. > > For encoding there is normally a single buffer split 'virtually' into k > pieces. To make all pieces starting at an aligned address one needs to align > the chunk size to e.g. 16*k. For the best possible performance on all > platforms we should change the get_alignment function in the ISA plug-in to > return 32*k if there are no other objections ?!?! > > Cheers Andreas. > > From: ceph-devel-ow...@vger.kernel.org [ceph-devel-ow...@vger.kernel.org] on > behalf of Janne Grunau [j...@jannau.net] > Sent: 18 September 2014 12:33 > To: ceph-devel@vger.kernel.org > Subject: v2 aligned buffer changes for erasure codes > > Hi, > > following a is an updated patchset. It passes now make check in src > > It has following changes: > * use 32-byte alignment since the isa plugin use AVX2 >(src/erasure-code/isa/README claims it needs 16*k byte aligned buffers >but I can't see a reason why it would need more than 32-bytes > * ErasureCode::encode_prepare() handles more than one chunk with padding > > cheers > > Janne > -- > 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 > -- Loïc Dachary, Artisan Logiciel Libre signature.asc Description: OpenPGP digital signature
RE: severe librbd performance degradation in Giant
My bad , with latest master , we got ~ 120K IOPS. Cheers, xinxin -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Shu, Xinxin Sent: Friday, September 19, 2014 9:08 AM To: Somnath Roy; Alexandre DERUMIER; Haomai Wang Cc: Sage Weil; Josh Durgin; ceph-devel@vger.kernel.org Subject: RE: severe librbd performance degradation in Giant I also observed performance degradation on my full SSD setup , I can got ~270K IOPS for 4KB random read with 0.80.4 , but with latest master , I only got ~12K IOPS Cheers, xinxin -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy Sent: Friday, September 19, 2014 2:03 AM To: Alexandre DERUMIER; Haomai Wang Cc: Sage Weil; Josh Durgin; ceph-devel@vger.kernel.org Subject: RE: severe librbd performance degradation in Giant Alexandre, What tool are you using ? I used fio rbd. Also, I hope you have Giant package installed in the client side as well and rbd_cache =true is set on the client conf file. FYI, firefly librbd + librados and Giant cluster will work seamlessly and I had to make sure fio rbd is really loading giant librbd (if you have multiple copies around , which was in my case) for reproducing it. Thanks & Regards Somnath -Original Message- From: Alexandre DERUMIER [mailto:aderum...@odiso.com] Sent: Thursday, September 18, 2014 2:49 AM To: Haomai Wang Cc: Sage Weil; Josh Durgin; ceph-devel@vger.kernel.org; Somnath Roy Subject: Re: severe librbd performance degradation in Giant >>According http://tracker.ceph.com/issues/9513, do you mean that rbd >>cache will make 10x performance degradation for random read? Hi, on my side, I don't see any degradation performance on read (seq or rand) with or without. firefly : around 12000iops (with or without rbd_cache) giant : around 12000iops (with or without rbd_cache) (and I can reach around 2-3 iops on giant with disabling optracker). rbd_cache only improve write performance for me (4k block ) - Mail original - De: "Haomai Wang" À: "Somnath Roy" Cc: "Sage Weil" , "Josh Durgin" , ceph-devel@vger.kernel.org Envoyé: Jeudi 18 Septembre 2014 04:27:56 Objet: Re: severe librbd performance degradation in Giant According http://tracker.ceph.com/issues/9513, do you mean that rbd cache will make 10x performance degradation for random read? On Thu, Sep 18, 2014 at 7:44 AM, Somnath Roy wrote: > Josh/Sage, > I should mention that even after turning off rbd cache I am getting ~20% > degradation over Firefly. > > Thanks & Regards > Somnath > > -Original Message- > From: Somnath Roy > Sent: Wednesday, September 17, 2014 2:44 PM > To: Sage Weil > Cc: Josh Durgin; ceph-devel@vger.kernel.org > Subject: RE: severe librbd performance degradation in Giant > > Created a tracker for this. > > http://tracker.ceph.com/issues/9513 > > Thanks & Regards > Somnath > > -Original Message- > From: ceph-devel-ow...@vger.kernel.org > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy > Sent: Wednesday, September 17, 2014 2:39 PM > To: Sage Weil > Cc: Josh Durgin; ceph-devel@vger.kernel.org > Subject: RE: severe librbd performance degradation in Giant > > Sage, > It's a 4K random read. > > Thanks & Regards > Somnath > > -Original Message- > From: Sage Weil [mailto:sw...@redhat.com] > Sent: Wednesday, September 17, 2014 2:36 PM > To: Somnath Roy > Cc: Josh Durgin; ceph-devel@vger.kernel.org > Subject: RE: severe librbd performance degradation in Giant > > What was the io pattern? Sequential or random? For random a slowdown makes > sense (tho maybe not 10x!) but not for sequentail > > s > > On Wed, 17 Sep 2014, Somnath Roy wrote: > >> I set the following in the client side /etc/ceph/ceph.conf where I am >> running fio rbd. >> >> rbd_cache_writethrough_until_flush = false >> >> But, no difference. BTW, I am doing Random read, not write. Still this >> setting applies ? >> >> Next, I tried to tweak the rbd_cache setting to false and I *got back* the >> old performance. Now, it is similar to firefly throughput ! >> >> So, loks like rbd_cache=true was the culprit. >> >> Thanks Josh ! >> >> Regards >> Somnath >> >> -Original Message- >> From: Josh Durgin [mailto:josh.dur...@inktank.com] >> Sent: Wednesday, September 17, 2014 2:20 PM >> To: Somnath Roy; ceph-devel@vger.kernel.org >> Subject: Re: severe librbd performance degradation in Giant >> >> On 09/17/2014 01:55 PM, Somnath Roy wrote: >> > H
Re: Inject configuration change into cluster
Ok, but in global case, when i use, a chef/puppet or any other, i wish
to change configuration in ceph.conf, and reload daemon to get new
configuration changes from ceph.conf, this feature would be very
helpful in ceph administration.
Inject is ok, for testing, or debuging.
On Tue, Sep 4, 2012 at 5:34 PM, Sage Weil wrote:
> On Tue, 4 Sep 2012, Wido den Hollander wrote:
>> On 09/04/2012 10:30 AM, Skowron S?awomir wrote:
>> > Ok, thanks.
>> >
>> > Number of workers used for recover, or numer of disk threads.
>> >
>>
>> I think those can be changed while the OSD is running. You could always give
>> it a try.
>
> The thread pool sizes can't currently be adjusted, unfortunately. It
> wouldn't be too difficult to change that...
>
> sage
>
>>
>> Wido
>>
>> > -Original Message-
>> > From: Wido den Hollander [mailto:w...@widodh.nl]
>> > Sent: Tuesday, September 04, 2012 10:18 AM
>> > To: Skowron S?awomir
>> > Cc: ceph-devel@vger.kernel.org
>> > Subject: Re: Inject configuration change into cluster
>> >
>> > On 09/04/2012 07:04 AM, Skowron S?awomir wrote:
>> > > Is there any way now, to inject new configuration change, without
>> > > restarting daemons ??
>> > >
>> >
>> > Yes, you can use the injectargs command.
>> >
>> > $ ceph osd tell 0 injectargs '--debug-osd 20'
>> >
>> > What do you want to change? Not everything can be changed while the OSD is
>> > running.
>> >
>> > Wido
>> >
>> > > Regards
>> > >
>> > > Slawomir Skowron--
>> > > 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
>> > >
>> >
>> > N???r??y?b???X???v???^???)?{.n???+?z???]z???{ay???
>> > ?,j ??f?h?z??? ???w?
>> > ?j:+v?w???j???m????
>> > zZ+???j"??!tml=
>> >
>>
>> --
>> 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
--
-
Pozdrawiam
Sławek "sZiBis" Skowron
--
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] osd/erasurecode: Fix memory leak in jerasure_matrix_to_bitmatrix()
On 04/11/2013 18:44, philippe.rai...@orange.com wrote:
> Hi !
>
> In this case, it should be more efficient to do the NULL check before the
> talloc (you'll save the free operation and a useless memory allocation)
>
Hi,
The check is on bitmatrix actually ;-)
Cheers
> Cheers,
> Philippe
>
>
> -Message d'origine-
> De : ceph-devel-ow...@vger.kernel.org
> [mailto:ceph-devel-ow...@vger.kernel.org] De la part de Loic Dachary
> Envoyé : samedi 2 novembre 2013 10:17
> À : Sage Weil; Xing Lin
> Cc : ceph-devel@vger.kernel.org
> Objet : Re: [PATCH] osd/erasurecode: Fix memory leak in
> jerasure_matrix_to_bitmatrix()
>
>
>
> On 02/11/2013 08:03, Sage Weil wrote:
>> Hi!
>>
>> On Sat, 2 Nov 2013, Xing Lin wrote:
>>> Free allocated memory before return because of NULL input
>>>
>>> Signed-off-by: Xing Lin
>>> ---
>>> src/osd/ErasureCodePluginJerasure/jerasure.c | 5 -
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/osd/ErasureCodePluginJerasure/jerasure.c
>>> b/src/osd/ErasureCodePluginJerasure/jerasure.c
>>> index 9efae02..1bb4b1d 100755
>>> --- a/src/osd/ErasureCodePluginJerasure/jerasure.c
>>> +++ b/src/osd/ErasureCodePluginJerasure/jerasure.c
>>> @@ -276,7 +276,10 @@ int *jerasure_matrix_to_bitmatrix(int k, int m, int w,
>>> int *matrix)
>>>int rowelts, rowindex, colindex, elt, i, j, l, x;
>>>
>>>bitmatrix = talloc(int, k*m*w*w);
>>> - if (matrix == NULL) { return NULL; }
>>> + if (matrix == NULL) {
>>> +free(bitmatrix);
>>> +return NULL;
>>> + }
>>
>> I have a feeling the author meant to say if (bitmatrix == NULL), since
>> all the other talloc calls in this file tend to be followed by a NULL check?
>
> Yes. Good catch Xing Lin :-)
>
> Cheers
>
>>
>> sage
>>
>>
>>>
>>>rowelts = k * w;
>>>rowindex = 0;
>>> --
>>> 1.8.3.4 (Apple Git-47)
>>>
>>> --
>>> 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
>>
>
> --
> Loïc Dachary, Artisan Logiciel Libre
>
> --
> 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
>
--
Loïc Dachary, Artisan Logiciel Libre
signature.asc
Description: OpenPGP digital signature
RE: A bug in FileStore::mount and A problem about XFS
On Thu, 14 Aug 2014, Ma, Jianpeng wrote: > I think you got the old code. I'm not find FX_TYPE_OTHER It was only recently removed in master. I suspect this bug is present in firefly, though, and should still be fixed! sage > > > > -Original Message- > > From: ceph-devel-ow...@vger.kernel.org > > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of n...@cs.hku.hk > > Sent: Thursday, August 14, 2014 12:08 PM > > To: ceph-devel@vger.kernel.org > > Subject: A bug in FileStore::mount and A problem about XFS > > > > > > Dear developers, > > > > I find a bug in FileStore::mount() function. If we use raw partitial as a > > Journal > > disk, like /dev/sda1, then it will cause a error when setting the parameters > > "m_filestore_max_inline_xattr_size" and "m_filestore_max_inline_xattrs". > > > > First of all, when creating the FileStore, it calls the mount() and detect > > fs_type > > as XFS, so it will check m_filestore_replica_fadvise(true default) and set > > it to > > false. At the same time, m_fs_tpye = FS_TYPE_XFS. > > > > However, when create JournalStore, it also enters mount() function and > > detect > > fs_type. Unfourtuanlly, this time, m_filestore_replica_fadvise = false so > > that it > > cannot update m_fs_type = FS_TYPE_XFS. Instread, it will sets to m_fs_tpye = > > FS_TYPE_OTHER. This bug is quite easy to repair. > > > > > > By the way, I wanna ask another question about XFS, I find that if I use > > ceph > > cluster heavily for about 2-3 hour. XFS always wakes up a kernel thread > > (xfsaild) > > to deal with its inodes reading and writing. > > This will impact the performance a lot and make the cluster's throughput > > drop > > heavily. So how to solve this problem and why this occurs after running a > > heavily > > read, write operation after 2-3 hour. > > > > Best Regards, > > Neal Yao > > -- > > 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: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params
Sound good. Thanks. -jiangang -Original Message- From: Somnath Roy [mailto:somnath@sandisk.com] Sent: Wednesday, October 08, 2014 10:53 AM To: Duan, Jiangang; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Hi Jiangang, Give me a day or two, I will gather all the data and share with community. Thanks & Regards Somnath -Original Message- From: Duan, Jiangang [mailto:jiangang.d...@intel.com] Sent: Wednesday, October 08, 2014 10:47 AM To: Somnath Roy; Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Can you guys share the w/ HT and w/o HT data? I want to take a look at that to understand why. -jiangang -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Somnath Roy Sent: Wednesday, October 08, 2014 10:38 AM To: Andreas Bluemle; ceph-devel@vger.kernel.org Subject: RE: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Thanks Andres for sharing this. I will try those out. BTW, I am using Ubuntu 14.04 LTS and couldn't find any sysfs entry like 'cpufreq'.. root@stormeap-4:~# ll /sys/devices/system/cpu/cpu10/ cache/crash_notes driver/ microcode/online subsystem/topology/ cpuidle/ crash_notes_size firmware_node/node0/power/ thermal_throttle/ uevent I am using Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz. Regards Somnath -Original Message- From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Andreas Bluemle Sent: Wednesday, October 08, 2014 9:33 AM To: ceph-devel@vger.kernel.org Subject: Re: 10/7/2014 Weekly Ceph Performance Meeting: kernel boot params Hi, as mentioned during today's meeting, here are the kernel boot parameters which I found to provide the basis for good performance results: processor.max_cstate=0 intel_idle.max_cstate=0 I understand these to basically turn off any power saving modes of the CPU; the CPU's we are using are like Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz At the BIOS level, we - turn off Hyperthraeding - turn off Turbo mode (in order ot not leave the specifications) - turn on frequency floor override We also assert that /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor is set to "performance" Using above we see a constant frequency at the maximum level allowed by the CPU (except Turbo mode). Best Regards Andreas Bluemle On Wed, 8 Oct 2014 02:51:21 +0200 Mark Nelson wrote: > Hi All, > > Just a remind that the weekly performance meeting is on Wednesdays at > 8AM PST. Same bat time, same bat channel! > > Etherpad URL: > http://pad.ceph.com/p/performance_weekly > > To join the Meeting: > https://bluejeans.com/268261044 > > To join via Browser: > https://bluejeans.com/268261044/browser > > To join with Lync: > https://bluejeans.com/268261044/lync > > > To join via Room System: > Video Conferencing System: bjn.vc -or- 199.48.152.152 Meeting ID: > 268261044 > > To join via Phone: > 1) Dial: >+1 408 740 7256 >+1 888 240 2560(US Toll Free) >+1 408 317 9253(Alternate Number) >(see all numbers - http://bluejeans.com/numbers) > 2) Enter Conference ID: 268261044 > > Mark > -- > 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 > > -- Andreas Bluemle mailto:andreas.blue...@itxperts.de ITXperts GmbH http://www.itxperts.de Balanstrasse 73, Geb. 08Phone: (+49) 89 89044917 D-81541 Muenchen (Germany) Fax: (+49) 89 89044910 Company details: http://www.itxperts.de/imprint.htm -- 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 PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stor
Confirmation for subscribe linux-8086
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-8086@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth ef15b755 subscribe linux-8086 archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth ef15b755 subscribe linux-8086 \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-8086-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-admin
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-admin@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth d0e53210 subscribe linux-admin archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth d0e53210 subscribe linux-admin \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-admin-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-alpha
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-alpha@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth d0782d10 subscribe linux-alpha archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth d0782d10 subscribe linux-alpha \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-alpha-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-apps
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-apps@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth eac17255 subscribe linux-apps archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth eac17255 subscribe linux-apps \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-apps-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-arch
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-arch@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth eac25955 subscribe linux-arch archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth eac25955 subscribe linux-arch \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-arch-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-assembly
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-assembly@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth b6efb7cc subscribe linux-assembly archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth b6efb7cc subscribe linux-assembly \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-assembly-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-bbs
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-bbs@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth b974de81 subscribe linux-bbs archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth b974de81 subscribe linux-bbs \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-bbs-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-config
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-config@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth 58c2ef43 subscribe linux-config archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth 58c2ef43 subscribe linux-config \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-config-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-console
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-console@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth f0d6f87b subscribe linux-console archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth f0d6f87b subscribe linux-console \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-console-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-diald
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-diald@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth d5396810 subscribe linux-diald archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth d5396810 subscribe linux-diald \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-diald-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-doc
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-doc@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth b9721e81 subscribe linux-doc archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth b9721e81 subscribe linux-doc \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-doc-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-fido
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-fido@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth eaa92e55 subscribe linux-fido archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth eaa92e55 subscribe linux-fido \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-fido-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-fsf
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-fsf@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth b971db81 subscribe linux-fsf archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth b971db81 subscribe linux-fsf \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-fsf-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-fsdevel
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-fsdevel@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth 3baf617f subscribe linux-fsdevel archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth 3baf617f subscribe linux-fsdevel \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-fsdevel-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-gcc
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-gcc@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth b971de81 subscribe linux-gcc archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth b971de81 subscribe linux-gcc \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-gcc-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-hams
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-hams@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth ea41a255 subscribe linux-hams archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth ea41a255 subscribe linux-hams \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-hams-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-ftp
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-ftp@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth b971bd81 subscribe linux-ftp archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth b971bd81 subscribe linux-ftp \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-ftp-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-ia64
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-ia64@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth ea54 subscribe linux-ia64 archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth ea54 subscribe linux-ia64 \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-ia64-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-ibcs2
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-ibcs2@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth d88ace10 subscribe linux-ibcs2 archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth d88ace10 subscribe linux-ibcs2 \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-ibcs2-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-ipx
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-ipx@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth b97ef581 subscribe linux-ipx archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth b97ef581 subscribe linux-ipx \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-ipx-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-isdn
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-isdn@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth ea432f55 subscribe linux-isdn archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth ea432f55 subscribe linux-isdn \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-isdn-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-ide
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-ide@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth b97fa881 subscribe linux-ide archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth b97fa881 subscribe linux-ide \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-ide-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-kernel
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-kernel@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth d30a2443 subscribe linux-kernel archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth d30a2443 subscribe linux-kernel \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-kernel-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-linuxss
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-linuxss@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth 90a01e74 subscribe linux-linuxss archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth 90a01e74 subscribe linux-linuxss \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-linuxss-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-lugnuts
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-lugnuts@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth 581d6e75 subscribe linux-lugnuts archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth 581d6e75 subscribe linux-lugnuts \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-lugnuts-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-laptop
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-laptop@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth a7309843 subscribe linux-laptop archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth a7309843 subscribe linux-laptop \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-laptop-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-m68k
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-m68k@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth ea43ea55 subscribe linux-m68k archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth ea43ea55 subscribe linux-m68k \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-m68k-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-mca
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-mca@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth b97bdc81 subscribe linux-mca archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth b97bdc81 subscribe linux-mca \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-mca-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
Confirmation for subscribe linux-mips
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "linux-mips@vger.kernel.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@vger.kernel.org": auth ea187255 subscribe linux-mips archive@mail-archive.com If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth ea187255 subscribe linux-mips \ archive@mail-archive.com If you have any questions about the policy of the list owner, please contact "linux-mips-approval@vger.kernel.org". Thanks! Majordomo@vger.kernel.org
