[jira] [Commented] (MESOS-970) Upgrade bundled leveldb to 1.19
[ https://issues.apache.org/jira/browse/MESOS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15426498#comment-15426498 ] Bing Li commented on MESOS-970: --- Thanks, Tomasz 1.19 works fine for me and "MESOS_BENCHMARK=1 GTEST_FILTER="*BENCHMARK*.*/1" make check" passed as well. > Upgrade bundled leveldb to 1.19 > --- > > Key: MESOS-970 > URL: https://issues.apache.org/jira/browse/MESOS-970 > Project: Mesos > Issue Type: Improvement > Components: replicated log >Reporter: Benjamin Mahler >Assignee: Tomasz Janiszewski > > We currently bundle leveldb 1.4, and the latest version is leveldb 1.19. > A careful review of the fixes and changes in each release would be prudent. > Regression testing and performance testing would also be prudent, given the > replicated log is built on leveldb. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-970) Upgrade bundled leveldb to 1.18
[ https://issues.apache.org/jira/browse/MESOS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417907#comment-15417907 ] Bing Li commented on MESOS-970: --- Thanks Guangya for pointing out which change caused the test case increase. I've tried the filter "*BENCHMARK*.*/1". [--] Global test environment tear-down [==] 8 tests from 4 test cases ran. (1973762 ms total) [ PASSED ] 8 tests. It only took approximately half an hour and all passed. We may have to reconsider what subset of test cases is necessary as regular use. "*BENCHMARK*" takes too long. I've stopped the run which started 2 weeks ago. > Upgrade bundled leveldb to 1.18 > --- > > Key: MESOS-970 > URL: https://issues.apache.org/jira/browse/MESOS-970 > Project: Mesos > Issue Type: Improvement > Components: replicated log >Reporter: Benjamin Mahler >Assignee: Tomasz Janiszewski > > We currently bundle leveldb 1.4, and the latest version is leveldb 1.18. > Upgrade to 1.18 could solve the problems when build Mesos in some non-x86 > architecture CPU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-970) Upgrade bundled leveldb to 1.18
[ https://issues.apache.org/jira/browse/MESOS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408302#comment-15408302 ] Bing Li commented on MESOS-970: --- It has been running for a week and still didn't finish. Didn't see any errors. It's still going. Looks like it spends most of the time on SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.DeclineOffers. [ OK ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.DeclineOffers/0 (2274 ms) [ OK ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.DeclineOffers/1 (961218 ms) [ OK ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.DeclineOffers/2 (6008455 ms) [ OK ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.DeclineOffers/3 (16382221 ms) [ OK ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.DeclineOffers/4 (105058559 ms) [ OK ] SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.DeclineOffers/5 (372416826 ms) Now my s390x machine is running DeclineOffers/6. And I have also an x86 machine which I started the run a little later. It's running DeclineOffers/5. I'm afraid the benchmark test takes too long. Not sure the test case SlaveAndFrameworkCount/HierarchicalAllocator_BENCHMARK_Test.DeclineOffers is changed on purpose or by accident. > Upgrade bundled leveldb to 1.18 > --- > > Key: MESOS-970 > URL: https://issues.apache.org/jira/browse/MESOS-970 > Project: Mesos > Issue Type: Improvement > Components: replicated log >Reporter: Benjamin Mahler >Assignee: Tomasz Janiszewski > > We currently bundle leveldb 1.4, and the latest version is leveldb 1.18. > Upgrade to 1.18 could solve the problems when build Mesos in some non-x86 > architecture CPU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-970) Upgrade bundled leveldb to 1.18
[ https://issues.apache.org/jira/browse/MESOS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15394431#comment-15394431 ] Bing Li commented on MESOS-970: --- I see. "-j" does make compile faster. I thought it would help the bench test cases too. Compared with the log you posted at https://gist.github.com/haosdent/ce2544d92c21314571f5a7c4312eb2dc#file-mesos_1-4_bench-txt-L4 . It seems there are much more test cases to run now. For instance, In your log, I saw 2 times "round 0" ... to "round 399". (400 * 2 = 800 in total.) In mine, there are at least a couple of thousands of "round n allocate() ..". And it is "... to make 1000 offers" now, vs yours "... to make 200 offers". At the end of your log. I saw "[==] 74 tests from 2 test cases ran. (51732372 ms total)". (51732372 ms = 14.37 hours). I gave up my run because it took too long. I thought there was something wrong. I finished the run a couple of weeks ago. But now it will take much longer. I'll rerun my bench test and share the log. Is the super long bench test as expected? Do you mind running the latest master branch to have a look? My concern is that since the test cases changed quite a lot, it won't be a fair comparison between leveldb 1.4 and 1.18. I also have 8 core X86 machine running master branch. It is not fast either. Thanks, > Upgrade bundled leveldb to 1.18 > --- > > Key: MESOS-970 > URL: https://issues.apache.org/jira/browse/MESOS-970 > Project: Mesos > Issue Type: Improvement > Components: replicated log >Reporter: Benjamin Mahler >Assignee: Tomasz Janiszewski > > We currently bundle leveldb 1.4, and the latest version is leveldb 1.18. > Upgrade to 1.18 could solve the problems when build Mesos in some non-x86 > architecture CPU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-970) Upgrade bundled leveldb to 1.18
[ https://issues.apache.org/jira/browse/MESOS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393919#comment-15393919 ] Bing Li commented on MESOS-970: --- I got an 18-core machine to test. "-j" didn't freeze my machine. Just noticed, no matter "-j" or "-j 18", it's strange that there are only 1-2 cores are busy. All the others are idle during the benchmark test. This must be the reason why it was so slow. I'm looking into it. > Upgrade bundled leveldb to 1.18 > --- > > Key: MESOS-970 > URL: https://issues.apache.org/jira/browse/MESOS-970 > Project: Mesos > Issue Type: Improvement > Components: replicated log >Reporter: Benjamin Mahler >Assignee: Tomasz Janiszewski > > We currently bundle leveldb 1.4, and the latest version is leveldb 1.18. > Upgrade to 1.18 could solve the problems when build Mesos in some non-x86 > architecture CPU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-970) Upgrade bundled leveldb to 1.18
[ https://issues.apache.org/jira/browse/MESOS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392257#comment-15392257 ] Bing Li commented on MESOS-970: --- [~haosd...@gmail.com] [~janisz], do you think we should apply the patch on 0.28.x branch? It seems master branch is changing fast. I've updated my master branch last week and there are much more test cases than a few weeks ago. The leveldb builtin db_bench program works fine and fast. But "make bench -j GTEST_FILTER="*BENCHMARK*"" takes really long (more than one day). I also noticed some test cases take a couple seconds to make 1000 offers and some take a couple of minutes to make 0 offers. Is it normal? Like the following: round 997 allocate() took 1.4235985052mins to make 1000 offers round 998 allocate() took 1.74531337935mins to make 1000 offers round 999 allocate() took 7.96837269378333mins to make 0 offers round 1000 allocate() took 8.79438932495mins to make 0 offers Thanks, > Upgrade bundled leveldb to 1.18 > --- > > Key: MESOS-970 > URL: https://issues.apache.org/jira/browse/MESOS-970 > Project: Mesos > Issue Type: Improvement > Components: replicated log >Reporter: Benjamin Mahler >Assignee: Tomasz Janiszewski > > We currently bundle leveldb 1.4, and the latest version is leveldb 1.18. > Upgrade to 1.18 could solve the problems when build Mesos in some non-x86 > architecture CPU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-970) Upgrade bundled leveldb to 1.18
[ https://issues.apache.org/jira/browse/MESOS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15385993#comment-15385993 ] Bing Li commented on MESOS-970: --- The levebdb 1.18 db_bench works fine on my s390x VM. We're comparing with different leveldb version and different machines. $ ./db_bench LevelDB:version 1.18 Date: Wed Jul 20 10:57:03 2016 CPU:0 * CPUCache: Keys: 16 bytes each Values: 100 bytes each (50 bytes after compression) Entries:100 RawSize:110.6 MB (estimated) FileSize: 62.9 MB (estimated) WARNING: Snappy compression is not enabled fillseq : 5.360 micros/op; 20.6 MB/s fillsync :9567.305 micros/op;0.0 MB/s (1000 ops) fillrandom : 13.688 micros/op;8.1 MB/s overwrite: 16.409 micros/op;6.7 MB/s readrandom : 8.835 micros/op; (100 of 100 found) readrandom : 7.297 micros/op; (100 of 100 found) readseq : 0.551 micros/op; 200.6 MB/s readreverse : 1.239 micros/op; 89.3 MB/s compact : 2996019.000 micros/op; readrandom : 5.786 micros/op; (100 of 100 found) readseq : 0.486 micros/op; 227.4 MB/s readreverse : 0.909 micros/op; 121.6 MB/s fill100K :5466.339 micros/op; 17.4 MB/s (1000 ops) crc32c : 5.183 micros/op; 753.6 MB/s (4K per op) snappycomp :4101.000 micros/op; (snappy failure) snappyuncomp :4888.000 micros/op; (snappy failure) acquireload : 0.582 micros/op; (each op is 1000 loads) > Upgrade bundled leveldb to 1.18 > --- > > Key: MESOS-970 > URL: https://issues.apache.org/jira/browse/MESOS-970 > Project: Mesos > Issue Type: Improvement > Components: replicated log >Reporter: Benjamin Mahler >Assignee: Tomasz Janiszewski > > We currently bundle leveldb 1.4, and the latest version is leveldb 1.18. > Upgrade to 1.18 could solve the problems when build Mesos in some non-x86 > architecture CPU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-970) Upgrade bundled leveldb to 1.18
[ https://issues.apache.org/jira/browse/MESOS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15382575#comment-15382575 ] Bing Li commented on MESOS-970: --- He didn't see any error messages saying a test case failed. But the run hung there forever. The strange thing is that the benchmark test passed for me. I was using an s390x VM with 16G ram. Not sure why it froze for him. > Upgrade bundled leveldb to 1.18 > --- > > Key: MESOS-970 > URL: https://issues.apache.org/jira/browse/MESOS-970 > Project: Mesos > Issue Type: Improvement > Components: replicated log >Reporter: Benjamin Mahler >Assignee: Tomasz Janiszewski > > We currently bundle leveldb 1.4, and the latest version is leveldb 1.18. > Upgrade to 1.18 could solve the problems when build Mesos in some non-x86 > architecture CPU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2201) ReplicaTest.Restore fails with leveldb greater than v1.7.
[
https://issues.apache.org/jira/browse/MESOS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15281888#comment-15281888
]
Bing Li commented on MESOS-2201:
I was working on MESOS-5288.
ReplicaTest.Restore failed on SLES12SP1 with leveldb 1.18 on s390x and I
confirm that the proposed fix resolves the problem.
> ReplicaTest.Restore fails with leveldb greater than v1.7.
> -
>
> Key: MESOS-2201
> URL: https://issues.apache.org/jira/browse/MESOS-2201
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 0.29.0
> Environment: E.g. Ubuntu 14.04.4 LTS + leveldb 1.10
>Reporter: Kapil Arya
>Assignee: Tomasz Janiszewski
>Priority: Minor
> Labels: mesosphere
> Fix For: 0.29.0
>
>
> I wanted to configure Mesos with system provided leveldb libraries when I ran
> into this issue. Apparently, if one does {{../configure
> --with-leveldb=/path/to/leveldb}}, compilation succeeds, however the
> "ReplicaTest_Restore" test fails with the following back trace:
> {code}
> [ RUN ] ReplicaTest.Restore
> Using temporary directory '/tmp/ReplicaTest_Restore_IZbbRR'
> I1222 14:16:49.517500 2927 leveldb.cpp:176] Opened db in 10.758917ms
> I1222 14:16:49.526495 2927 leveldb.cpp:183] Compacted db in 8.931146ms
> I1222 14:16:49.526523 2927 leveldb.cpp:198] Created db iterator in 5787ns
> I1222 14:16:49.526531 2927 leveldb.cpp:204] Seeked to beginning of db in
> 511ns
> I1222 14:16:49.526535 2927 leveldb.cpp:273] Iterated through 0 keys in the
> db in 197ns
> I1222 14:16:49.526623 2927 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1222 14:16:49.530972 2945 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 3.084458ms
> I1222 14:16:49.531008 2945 replica.cpp:320] Persisted replica status to
> VOTING
> I1222 14:16:49.541263 2927 leveldb.cpp:176] Opened db in 9.980586ms
> I1222 14:16:49.551636 2927 leveldb.cpp:183] Compacted db in 10.348096ms
> I1222 14:16:49.551683 2927 leveldb.cpp:198] Created db iterator in 3405ns
> I1222 14:16:49.551693 2927 leveldb.cpp:204] Seeked to beginning of db in
> 3559ns
> I1222 14:16:49.551728 2927 leveldb.cpp:273] Iterated through 1 keys in the
> db in 29722ns
> I1222 14:16:49.551751 2927 replica.cpp:741] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1222 14:16:49.551996 2947 replica.cpp:474] Replica received implicit
> promise request with proposal 1
> I1222 14:16:49.560921 2947 leveldb.cpp:306] Persisting metadata (8 bytes) to
> leveldb took 8.899591ms
> I1222 14:16:49.560940 2947 replica.cpp:342] Persisted promised to 1
> I1222 14:16:49.561338 2943 replica.cpp:508] Replica received write request
> for position 1
> I1222 14:16:49.568677 2943 leveldb.cpp:343] Persisting action (27 bytes) to
> leveldb took 7.287155ms
> I1222 14:16:49.568692 2943 replica.cpp:676] Persisted action at 1
> I1222 14:16:49.569042 2942 leveldb.cpp:438] Reading position from leveldb
> took 26339ns
> F1222 14:16:49.569411 2927 replica.cpp:721] CHECK_SOME(state): IO error:
> lock /tmp/ReplicaTest_Restore_IZbbRR/.log/LOCK: already held by process
> Failed to recover the log
> *** Check failure stack trace: ***
> @ 0x7f7f6c53e688 google::LogMessage::Fail()
> @ 0x7f7f6c53e5e7 google::LogMessage::SendToLog()
> @ 0x7f7f6c53dff8 google::LogMessage::Flush()
> @ 0x7f7f6c540d2c google::LogMessageFatal::~LogMessageFatal()
> @ 0x90a520 _CheckFatal::~_CheckFatal()
> @ 0x7f7f6c400f4d mesos::internal::log::ReplicaProcess::restore()
> @ 0x7f7f6c3fd763
> mesos::internal::log::ReplicaProcess::ReplicaProcess()
> @ 0x7f7f6c401271 mesos::internal::log::Replica::Replica()
> @ 0xcd7ca3 ReplicaTest_Restore_Test::TestBody()
> @ 0x10934b2
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @ 0x108e584
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @ 0x10768fd testing::Test::Run()
> @ 0x1077020 testing::TestInfo::Run()
> @ 0x10775a8 testing::TestCase::Run()
> @ 0x107c324 testing::internal::UnitTestImpl::RunAllTests()
> @ 0x1094348
> testing::internal::HandleSehExceptionsInMethodIfSupported<>()
> @ 0x108f2b7
> testing::internal::HandleExceptionsInMethodIfSupported<>()
> @ 0x107b1d4 testing::UnitTest::Run()
> @ 0xd344a9 main
> @ 0x7f7f66fdfb45 __libc_start_main
> @ 0x8f3549 (unknown)
> @ (nil) (unknown)
> [2]2927 abort (core dumped) GLOG_logtostderr=1 GTEST_v=10
> ./bin/mesos-tests.sh --verbose
> {code}
> The bundled version
[jira] [Commented] (MESOS-5288) Update leveldb patch file to suport s390x
[ https://issues.apache.org/jira/browse/MESOS-5288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278606#comment-15278606 ] Bing Li commented on MESOS-5288: Great. I guess you meant v1.18. I'll update leveldb and try the patch provided in MESOS-2201. Thanks, > Update leveldb patch file to suport s390x > - > > Key: MESOS-5288 > URL: https://issues.apache.org/jira/browse/MESOS-5288 > Project: Mesos > Issue Type: Bug >Reporter: Bing Li >Assignee: Bing Li > > There're 2 issues in leveldb-1.4. > 1. Leveldb didn't build. Have to define MemoryBarrier() for s390x. > I got the patch form https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644336 > . > 2. A number of unit tests failed due to 1.4 doesn't detect endianness > properly. And s390x is big-endian. > Got error messages like "Failed to recover the log: Corruption: checksum > mismatch". > I have a backport patch which is part of the leveldb commit > https://github.com/google/leveldb/commit/075a35a6d390167b77b687e067dd0ba593e7f624 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5242) pivot_root is not available on System z (s390x)
[ https://issues.apache.org/jira/browse/MESOS-5242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278095#comment-15278095 ] Bing Li commented on MESOS-5242: As https://reviews.apache.org/r/46730/ is already in master branch, I've tried it out and it works for s390x. Closing this issue. BTW, [~haosd...@gmail.com] do you mind having a look at the other porting issue MESOS-5288 which is realted to leveldb ? Thanks, > pivot_root is not available on System z (s390x) > --- > > Key: MESOS-5242 > URL: https://issues.apache.org/jira/browse/MESOS-5242 > Project: Mesos > Issue Type: Bug > Environment: Hardward: IBM System z > OS: Linux on z SLES12SP1 >Reporter: Bing Li >Assignee: Bing Li > > Got error "pivot_root is not available" which is similar to MESOS-5121 . > Added syscall pivot_root definition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-5242) pivot_root is not available on System z (s390x)
[ https://issues.apache.org/jira/browse/MESOS-5242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bing Li updated MESOS-5242: --- Comment: was deleted (was: As https://reviews.apache.org/r/46730/ is already in master branch, I've tried it out and it works for s390x. Closing this issue. BTW, [~haosd...@gmail.com] do you mind having a look at the other porting issue MESOS-5288 which is realted to leveldb ? Thanks,) > pivot_root is not available on System z (s390x) > --- > > Key: MESOS-5242 > URL: https://issues.apache.org/jira/browse/MESOS-5242 > Project: Mesos > Issue Type: Bug > Environment: Hardward: IBM System z > OS: Linux on z SLES12SP1 >Reporter: Bing Li >Assignee: Bing Li > > Got error "pivot_root is not available" which is similar to MESOS-5121 . > Added syscall pivot_root definition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5288) Update leveldb patch file to suport s390x
[ https://issues.apache.org/jira/browse/MESOS-5288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272401#comment-15272401 ] Bing Li commented on MESOS-5288: I've tried the latest release version v1.18. It built successfully. But the test case "ReplicaTest_Restore" failed which is also mentioned in MESOS-2201 . Ended up I backported the endianness detection fix. And it didn't break any test cases. > Update leveldb patch file to suport s390x > - > > Key: MESOS-5288 > URL: https://issues.apache.org/jira/browse/MESOS-5288 > Project: Mesos > Issue Type: Bug >Reporter: Bing Li >Assignee: Bing Li > > There're 2 issues in leveldb-1.4. > 1. Leveldb didn't build. Have to define MemoryBarrier() for s390x. > I got the patch form https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644336 > . > 2. A number of unit tests failed due to 1.4 doesn't detect endianness > properly. And s390x is big-endian. > Got error messages like "Failed to recover the log: Corruption: checksum > mismatch". > I have a backport patch which is part of the leveldb commit > https://github.com/google/leveldb/commit/075a35a6d390167b77b687e067dd0ba593e7f624 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5288) Update leveldb patch file to suport s390x
Bing Li created MESOS-5288: -- Summary: Update leveldb patch file to suport s390x Key: MESOS-5288 URL: https://issues.apache.org/jira/browse/MESOS-5288 Project: Mesos Issue Type: Bug Reporter: Bing Li Assignee: Bing Li There're 2 issues in leveldb-1.4. 1. Leveldb didn't build. Have to define MemoryBarrier() for s390x. I got the patch form https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644336 . 2. A number of unit tests failed due to 1.4 doesn't detect endianness properly. And s390x is big-endian. Got error messages like "Failed to recover the log: Corruption: checksum mismatch". I have a backport patch which is part of the leveldb commit https://github.com/google/leveldb/commit/075a35a6d390167b77b687e067dd0ba593e7f624 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5242) pivot_root is not available on System z (s390x)
[ https://issues.apache.org/jira/browse/MESOS-5242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15258144#comment-15258144 ] Bing Li commented on MESOS-5242: Hi haosdent, I had a look at MESOS-5263. And yes, the definition of syscall pivot_root won't be needed when we have "+#include " . I'll keep an eye on 5263. Once the 5263 fix is approved, I'll try it out and close this issue. Thanks, > pivot_root is not available on System z (s390x) > --- > > Key: MESOS-5242 > URL: https://issues.apache.org/jira/browse/MESOS-5242 > Project: Mesos > Issue Type: Bug > Environment: Hardward: IBM System z > OS: Linux on z SLES12SP1 >Reporter: Bing Li >Assignee: Bing Li > > Got error "pivot_root is not available" which is similar to MESOS-5121 . > Added syscall pivot_root definition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5242) pivot_root is not available on System z (s390x)
[ https://issues.apache.org/jira/browse/MESOS-5242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bing Li reassigned MESOS-5242: -- Assignee: Bing Li > pivot_root is not available on System z (s390x) > --- > > Key: MESOS-5242 > URL: https://issues.apache.org/jira/browse/MESOS-5242 > Project: Mesos > Issue Type: Bug > Environment: Hardward: IBM System z > OS: Linux on z SLES12SP1 >Reporter: Bing Li >Assignee: Bing Li > > Got error "pivot_root is not available" which is similar to MESOS-5121 . > Added syscall pivot_root definition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5241) Porting Mesos to System z (s390x)
[ https://issues.apache.org/jira/browse/MESOS-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252390#comment-15252390 ] Bing Li commented on MESOS-5241: I'm sending a email to d...@mesos.apache.org . Thanks, > Porting Mesos to System z (s390x) > - > > Key: MESOS-5241 > URL: https://issues.apache.org/jira/browse/MESOS-5241 > Project: Mesos > Issue Type: Epic >Reporter: Bing Li > > The goal of this ticket is to make IBM System z (s390x) as a supported > architecture. > The latest Mesos release version or master branch didn't built successfully > on s390x. > We'll contribute our patches to make Mesos work on s390x . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5242) pivot_root is not available on System z (s390x)
[ https://issues.apache.org/jira/browse/MESOS-5242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252389#comment-15252389 ] Bing Li commented on MESOS-5242: Hi, I have the patch already. It seems I'll need a reviewer, so that I can public my patch in Review Board. Thanks, > pivot_root is not available on System z (s390x) > --- > > Key: MESOS-5242 > URL: https://issues.apache.org/jira/browse/MESOS-5242 > Project: Mesos > Issue Type: Bug > Environment: Hardward: IBM System z > OS: Linux on z SLES12SP1 >Reporter: Bing Li > > Got error "pivot_root is not available" which is similar to MESOS-5121 . > Added syscall pivot_root definition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5242) pivot_root is not available on System z (s390x)
[ https://issues.apache.org/jira/browse/MESOS-5242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bing Li updated MESOS-5242: --- Description: Got error "pivot_root is not available" which is similar to MESOS-5121 . Added syscall pivot_root definition. was: It is similar as MESOS-5121 . Added syscall pivot_root definition. > pivot_root is not available on System z (s390x) > --- > > Key: MESOS-5242 > URL: https://issues.apache.org/jira/browse/MESOS-5242 > Project: Mesos > Issue Type: Bug > Environment: Hardward: IBM System z > OS: Linux on z SLES12SP1 >Reporter: Bing Li > > Got error "pivot_root is not available" which is similar to MESOS-5121 . > Added syscall pivot_root definition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5242) pivot_root is not available on System z (s390x)
Bing Li created MESOS-5242: -- Summary: pivot_root is not available on System z (s390x) Key: MESOS-5242 URL: https://issues.apache.org/jira/browse/MESOS-5242 Project: Mesos Issue Type: Bug Environment: Hardward: IBM System z OS: Linux on z SLES12SP1 Reporter: Bing Li It is similar as MESOS-5121 . Added syscall pivot_root definition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5241) Porting Mesos to System z (s390x)
[ https://issues.apache.org/jira/browse/MESOS-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252353#comment-15252353 ] Bing Li commented on MESOS-5241: Hi there, I'm enabling Mesos on System z. Maybe assign this Epic to me? I'll open related issues under it. Thanks, > Porting Mesos to System z (s390x) > - > > Key: MESOS-5241 > URL: https://issues.apache.org/jira/browse/MESOS-5241 > Project: Mesos > Issue Type: Epic >Reporter: Bing Li > > The goal of this ticket is to make IBM System z (s390x) as a supported > architecture. > The latest Mesos release version or master branch didn't built successfully > on s390x. > We'll contribute our patches to make Mesos work on s390x . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5241) Porting Mesos to System z (s390x)
Bing Li created MESOS-5241: -- Summary: Porting Mesos to System z (s390x) Key: MESOS-5241 URL: https://issues.apache.org/jira/browse/MESOS-5241 Project: Mesos Issue Type: Epic Reporter: Bing Li The goal of this ticket is to make IBM System z (s390x) as a supported architecture. The latest Mesos release version or master branch didn't built successfully on s390x. We'll contribute our patches to make Mesos work on s390x . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
