Re: [ceph-users] cephfs quota
Would you give us some outputs? # getfattr -n ceph.quota.max_bytes /some/dir and # ls -l /some/dir On Thu, Dec 15, 2016 at 4:41 PM, gjprabuwrote: > > Hi Team, > > We are using ceph version 10.2.4 (Jewel) and data's are mounted > with cephfs file system in linux. We are trying to set quota for directory > and files but its don't worked with below document. I have set 100mb for > directory quota but after reaching keep me allowing to put the data in that > location. Highly appreciate any one help on this issue. > > http://docs.ceph.com/docs/jewel/cephfs/quota/ > > > Regards > Prabu GJ > > ___ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
[ceph-users] cephfs quota
Hi Team, We are using ceph version 10.2.4 (Jewel) and data's are mounted with cephfs file system in linux. We are trying to set quota for directory and files but its don't worked with below document. I have set 100mb for directory quota but after reaching keep me allowing to put the data in that location. Highly appreciate any one help on this issue. http://docs.ceph.com/docs/jewel/cephfs/quota/ Regards Prabu GJ ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] [Fixed] OS-Prober In Ubuntu Xenial causes journal errors
Hello, On Wed, 14 Dec 2016 16:23:18 - Nick Fisk wrote: > Hi All, > > For all those who have been hit by the bug in Ubuntu where update-grub causes > your OSD's to crash out when it probes the partition, > a fixed package has been released to xenial-proposed which fixes the problem. > I have installed and confirm it fixes the problem. > > https://launchpad.net/ubuntu/+source/os-prober/1.70ubuntu3.1 > Just for the record and since a major pet peeve of mine has been triggered: OS-prober is the FIRST thing thing I un-install on every last Debian machine of mine, as it has a long history of doing unwanted and outright bad things. Christian -- Christian BalzerNetwork/Systems Engineer ch...@gol.com Global OnLine Japan/Rakuten Communications http://www.gol.com/ ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] What happens if all replica OSDs journals are broken?
2016-12-14 2:37 GMT+01:00 Christian Balzer: > > Hello, > Hi! > > On Wed, 14 Dec 2016 00:06:14 +0100 Kevin Olbrich wrote: > > > Ok, thanks for your explanation! > > I read those warnings about size 2 + min_size 1 (we are using ZFS as > RAID6, > > called zraid2) as OSDs. > > > This is similar to my RAID6 or RAID10 backed OSDs with regards to having > very resilient, extremely unlikely to fail OSDs. > This was our intention (unlikely to fail, data security > performance). We use Ceph for OpenStack (Cinder RBD). > As such a Ceph replication of 2 with min_size is a calculated risk, > acceptable for me on others in certain use cases. > This is also with very few (2-3) journals per SSD. > We are running 14x 500G RAID6 ZFS-RAID per Host (1x journal, 1x OSD, 32GB RAM). The ZFS pools use L2ARC-Cache on Samsung 850 PRO's 128GB. Hint: Was a bad idea, would have better split the ZFS pools. (ZFS performance was very good but double parity with 4k random on sync with ceph takes very long, resulting in XXX requests blocked more than 32 seconds). Currently I am waiting for a lab cluster to test "osd op threads" for these single OSD hosts. > If: > > 1. Your journal SSDs are well trusted and monitored (Intel DC S36xx, 37xx) > Indeed Intel DC P3700 400GB for Ceph. We had Samsung 850 PRO before I leard 4k random while DSYNC is a very bad idea... ;-) 2. Your failure domain represented by a journal SSD is small enough > (meaning that replicating the lost OSDs can be done quickly) > OSDs are rather large but we are "just" using 8 TB (size 2) in the whole cluster (OSD is 24% full). Before we moved from infernalis to jewel, a recovery from an OSD which was offline for 8 hours took approx. one hour to be back in sync. it may be an acceptable risk for you as well. We got reliable backups in the past but downtime is a greater problem. > > > Time to raise replication! > > > If you can afford that (money, space, latency), definitely go for it. > It's more the double journal failure which scares me compared to the OSD itself (as ZFS was very reliable in the past). Kevin > Christian > > Kevin > > > > 2016-12-13 0:00 GMT+01:00 Christian Balzer : > > > > > On Mon, 12 Dec 2016 22:41:41 +0100 Kevin Olbrich wrote: > > > > > > > Hi, > > > > > > > > just in case: What happens when all replica journal SSDs are broken > at > > > once? > > > > > > > That would be bad, as in BAD. > > > > > > In theory you just "lost" all the associated OSDs and their data. > > > > > > In practice everything but in the in-flight data at the time is still > on > > > the actual OSDs (HDDs), but it's inconsistent and inaccessible as far > as > > > Ceph is concerned. > > > > > > So with some trickery and an experienced data-recovery Ceph consultant > you > > > _may_ get things running with limited data loss/corruption, but that's > > > speculation and may be wishful thinking on my part. > > > > > > Another data point to deploy only well known/monitored/trusted SSDs and > > > have a 3x replication. > > > > > > > The PGs most likely will be stuck inactive but as I read, the > journals > > > just > > > > need to be replaced (http://ceph.com/planet/ceph- > recover-osds-after-ssd- > > > > journal-failure/). > > > > > > > > Does this also work in this case? > > > > > > > Not really, no. > > > > > > The above works by having still a valid state and operational OSDs from > > > which the "broken" one can recover. > > > > > > Christian > > > -- > > > Christian BalzerNetwork/Systems Engineer > > > ch...@gol.com Global OnLine Japan/Rakuten Communications > > > http://www.gol.com/ > > > > > > -- > Christian BalzerNetwork/Systems Engineer > ch...@gol.com Global OnLine Japan/Rakuten Communications > http://www.gol.com/ > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] 10.2.3: Howto disable cephx_sign_messages and preventing a LogFlood
On Wed, Dec 14, 2016 at 5:10 PM, Bjoern Laessigwrote: > Hi, > > i triggered a Kernel bug in the ceph-krbd code > * http://www.spinics.net/lists/ceph-devel/msg33802.html The fix is ready and is set to be merged into 4.10-rc1. How often can you hit it? > > Ilya Dryomov wrote in a reply: The way to go is to \u201cdisabling cephx > message signing\u201d That's one option. Lightening the load on the client machine is another - this bug should only surface under high memory pressure. > > I have a lot of systems that use librbd and only 2 Hosts that user krbd. > I do not want to disable message-signing completely, so after trying to: > > rbd map mypool/myrbd --id dev --keyring /etc/ceph/ceph.client.dev.keyring > --options nocephx_sign_messages > > which lead to endless waiting. Strace says: > > [pid 10845] open("/sys/bus/rbd/add_single_major", O_WRONLY) = 4 > [pid 10845] write(4, > "[2001:67c:670:100:5054:ff:fe78:2a86]:6789,[2001:67c:670:100:5054:ff:fecf:22f6]:6789,[2001:67c:670:100:5054:ff:feae:42ee]:6789 > name=dev,key=client.dev,nocephx_sign_messages ptxdev WORK_CEPH_BLA -", 194 > > [pid 10899] <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) > [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 > [pid 10899] futex(0x55f66389555c, > FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 3, {1481729207, 622660011}, > ) = -1 ETIMEDOUT (Connection timed out) > [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 > [pid 10899] futex(0x55f66389555c, > FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 5, {1481729212, 622818887}, > ) = -1 ETIMEDOUT (Connection timed out) > [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 > [pid 10899] futex(0x55f66389555c, > FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 7, {1481729217, 622973709}, > ) = -1 ETIMEDOUT (Connection timed out) > [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 > [pid 10899] futex(0x55f66389555c, > FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 9, {1481729222, 623078200}, > ) = -1 ETIMEDOUT (Connection timed out) > [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 > [pid 10899] futex(0x55f66389555c, > FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 11, {1481729227, 623190181}, > ) = -1 ETIMEDOUT (Connection timed out) > [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 > [pid 10899] futex(0x55f66389555c, > FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 13, {1481729232, 623298560}, > ) = -1 ETIMEDOUT (Connection timed out) > [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 > [pid 10899] futex(0x55f66389555c, > FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 15, {1481729237, 623504923}, > ) = -1 ETIMEDOUT (Connection timed out) > [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 > [pid 10899] futex(0x55f66389555c, > FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 17, {1481729242, 623709707}, > ) = -1 ETIMEDOUT (Connection timed out) > [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 > [pid 10899] futex(0x55f66389555c, > FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 19, {1481729247, 623816985}, > ) = -1 ETIMEDOUT (Connection timed out) > [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 > (... cycle endless ) > > After failing with rbd-map-options, i set in /etc/ceph/ceph.conf: >> [global] >> cephx_sign_messages = false > > Now i have 1 (one) ceph-osd-process which starts logging an enormous > (4GBytes/hour) count of lines like: > > >> 2016-12-14 07:49:40.111415 7f25f0c0a700 0 SIGN: MSG 1 Sender did not set >> CEPH_MSG_FOOTER_SIGNED. >> 2016-12-14 07:49:40.111422 7f25f0c0a700 0 SIGN: MSG 1 Message signature >> does not match contents. >> 2016-12-14 07:49:40.111423 7f25f0c0a700 0 SIGN: MSG 1Signature on message: >> 2016-12-14 07:49:40.111425 7f25f0c0a700 0 SIGN: MSG 1sig: 0 >> 2016-12-14 07:49:40.111427 7f25f0c0a700 0 SIGN: MSG 1Locally calculated >> signature: >> 2016-12-14 07:49:40.111428 7f25f0c0a700 0 SIGN: MSG 1 >> sig_check:1990181984681779795 >> 2016-12-14 07:49:40.111429 7f25f0c0a700 0 Signature failed. >> 2016-12-14 07:49:40.111430 7f25f0c0a700 0 -- >> [myOsdNode1.ipv6.address]:6802/29624 >> >> [my_kRBD_client.ipv6.address]:0/943150662 pipe(0x5603813bd400 sd=121 :6802 >> s=2 pgs=353544735 cs=1 l=1 c=0x560381182900).Signature check failed > > Then i read on: > http://docs.ceph.com/docs/jewel/rados/troubleshooting/log-and-debug/ > that \u201cCeph\u2019s logging levels operate on a scale of 1 to 20, where 1 > is > terse and 20 is verbose.\u201d The Messages i got, had a loglevel of 0 so i > set the loglevel to -1. > >> ceph tell osd.3 injectargs --debug-auth -1 >> ceph tell osd.3 injectargs --debug-ms -1 > > to get rid of them. > > Actually i do not have to delete the logfiles every 12 hours, so my pain > has gone but its a workaround for a workaround. That is painful. What >
[ceph-users] [Fixed] OS-Prober In Ubuntu Xenial causes journal errors
Hi All, For all those who have been hit by the bug in Ubuntu where update-grub causes your OSD's to crash out when it probes the partition, a fixed package has been released to xenial-proposed which fixes the problem. I have installed and confirm it fixes the problem. https://launchpad.net/ubuntu/+source/os-prober/1.70ubuntu3.1 Nick ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
[ceph-users] 10.2.3: Howto disable cephx_sign_messages and preventing a LogFlood
Hi, i triggered a Kernel bug in the ceph-krbd code * http://www.spinics.net/lists/ceph-devel/msg33802.html Ilya Dryomov wrote in a reply: The way to go is to “disabling cephx message signing” I have a lot of systems that use librbd and only 2 Hosts that user krbd. I do not want to disable message-signing completely, so after trying to: rbd map mypool/myrbd --id dev --keyring /etc/ceph/ceph.client.dev.keyring --options nocephx_sign_messages which lead to endless waiting. Strace says: [pid 10845] open("/sys/bus/rbd/add_single_major", O_WRONLY) = 4 [pid 10845] write(4, "[2001:67c:670:100:5054:ff:fe78:2a86]:6789,[2001:67c:670:100:5054:ff:fecf:22f6]:6789,[2001:67c:670:100:5054:ff:feae:42ee]:6789 name=dev,key=client.dev,nocephx_sign_messages ptxdev WORK_CEPH_BLA -", 194 [pid 10899] <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 10899] futex(0x55f66389555c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 3, {1481729207, 622660011}, ) = -1 ETIMEDOUT (Connection timed out) [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 10899] futex(0x55f66389555c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 5, {1481729212, 622818887}, ) = -1 ETIMEDOUT (Connection timed out) [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 10899] futex(0x55f66389555c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 7, {1481729217, 622973709}, ) = -1 ETIMEDOUT (Connection timed out) [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 10899] futex(0x55f66389555c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 9, {1481729222, 623078200}, ) = -1 ETIMEDOUT (Connection timed out) [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 10899] futex(0x55f66389555c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 11, {1481729227, 623190181}, ) = -1 ETIMEDOUT (Connection timed out) [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 10899] futex(0x55f66389555c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 13, {1481729232, 623298560}, ) = -1 ETIMEDOUT (Connection timed out) [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 10899] futex(0x55f66389555c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 15, {1481729237, 623504923}, ) = -1 ETIMEDOUT (Connection timed out) [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 10899] futex(0x55f66389555c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 17, {1481729242, 623709707}, ) = -1 ETIMEDOUT (Connection timed out) [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 10899] futex(0x55f66389555c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 19, {1481729247, 623816985}, ) = -1 ETIMEDOUT (Connection timed out) [pid 10899] futex(0x55f663895508, FUTEX_WAKE_PRIVATE, 1) = 0 (... cycle endless ) After failing with rbd-map-options, i set in /etc/ceph/ceph.conf: > [global] > cephx_sign_messages = false Now i have 1 (one) ceph-osd-process which starts logging an enormous (4GBytes/hour) count of lines like: > 2016-12-14 07:49:40.111415 7f25f0c0a700 0 SIGN: MSG 1 Sender did not set > CEPH_MSG_FOOTER_SIGNED. > 2016-12-14 07:49:40.111422 7f25f0c0a700 0 SIGN: MSG 1 Message signature does > not match contents. > 2016-12-14 07:49:40.111423 7f25f0c0a700 0 SIGN: MSG 1Signature on message: > 2016-12-14 07:49:40.111425 7f25f0c0a700 0 SIGN: MSG 1sig: 0 > 2016-12-14 07:49:40.111427 7f25f0c0a700 0 SIGN: MSG 1Locally calculated > signature: > 2016-12-14 07:49:40.111428 7f25f0c0a700 0 SIGN: MSG 1 > sig_check:1990181984681779795 > 2016-12-14 07:49:40.111429 7f25f0c0a700 0 Signature failed. > 2016-12-14 07:49:40.111430 7f25f0c0a700 0 -- > [myOsdNode1.ipv6.address]:6802/29624 >> > [my_kRBD_client.ipv6.address]:0/943150662 pipe(0x5603813bd400 sd=121 :6802 > s=2 pgs=353544735 cs=1 l=1 c=0x560381182900).Signature check failed Then i read on: http://docs.ceph.com/docs/jewel/rados/troubleshooting/log-and-debug/ that “Ceph’s logging levels operate on a scale of 1 to 20, where 1 is terse and 20 is verbose.” The Messages i got, had a loglevel of 0 so i set the loglevel to -1. > ceph tell osd.3 injectargs --debug-auth -1 > ceph tell osd.3 injectargs --debug-ms -1 to get rid of them. Actually i do not have to delete the logfiles every 12 hours, so my pain has gone but its a workaround for a workaround. That is painful. What could i do to disable cephx-message-signing only for the krbd clients? Björn Lässig ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
[ceph-users] radosgw fastcgi problem
Hi: Very sorry for the last email, it was an accident. Recently, I trid to configure radosgw (0.94.7) with nginx as frontend, benchmark it with cosbench. And I found a strange thing. My os-related configuration are, net.core.netdev_max_backlog = 1000 net.core.somaxconn = 1024 In rgw_main.cc, I see #define SOCKET_BACKLOG 1024. so here is the problem. 1、When I configure cosbench with 1000 workers , everything is OK. But when it was 2000workers,there will be a lot of CLOSE_WAIT state connections on rgw side, and rgw will no longer response to any request.Use netstat command , I can see there are 1024 CLOSE_WAIT connections. 2、I change net.core.somaxconn to 128, and run cosbench with 2000 workers again, very soon, there will be no response from radosgw, and use netstat command , I can see there are 128 CLOSE_WAIT connections. I tried a lot things, googled it , but the problem still exist. I thought if there is some bug on fastcgi lib. Have anyone met this problem? ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
[ceph-users] radosgw fastcgi problem
Hi: Recently, I trid to configure radosgw with nginx as frontend, benchmark it with cosbench. And I found a strange thing. My os-related configuration are, net.core.netdev_max_backlog = 1000 ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com