Re: [CentOS] scp via another server
On June 12, 2016 4:05:59 PM EDT, Always Learning wrote: > >On Sun, 2016-06-12 at 20:43 +0200, H wrote: > >> There seems to be something broken when using scp between two remote >> locations. Some posts on the 'net suggest using 'scp -3' to do an >> intermediate copy to the workstation between the two remote servers >> but that option does not seem to have been implemented yet on scp for >> Centos 6.7. > >The current version of C6 is now C6.8 :-) > > > >-- >Regards, > >Paul. >England, EU. England's place is in the European Union. > >___ >CentOS mailing list >CentOS@centos.org >https://lists.centos.org/mailman/listinfo/centos You're right, that's indeed what I am running. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] scp via another server
On June 12, 2016 8:51:42 PM CEST, cpol...@surewest.net wrote: >On 2016-06-12 19:07, H wrote: >> On 06/12/2016 05:21 PM, J Martin Rushton wrote: >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA1 >> > >> > $ scp svr2:/path/to/source svr1:/path/to/dest >> > >> > You'll get twice the network traffic since the copy is running on >your >> > workstattoin (or whatever). >> > >> > On 12/06/16 15:40, H wrote: >> > > I normally use ssh to log into a remote server, change directory >> > > and then use scp from there to copy files from another remote >> > > server to the first one. >> > > >> > > Now the first server has been hit by continuous error correction >> > > messages from the ECC controller, all of which are corrected, and >I >> > > am unable to get a command line to issue the required commands to >> > > change directory and then run scp from the other server. I have >no >> > > problems, however, getting into the first server - except for >being >> > > drowned by the error correction messages and the server seems to >be >> > > running "fine". >> > > >> > > Until I am able to get to the server and investigate, is it >> > > possible to accomplish the above on a single command line, thus >> > > avoiding seeing the error messages? I should add that both the >> > > first and second server are set up to accept keys and not >passwords >> > > so at least I don't have to worry about that. > >Try changing kernel console log level to 0, possibly: > > echo '0 0 0 0' > /proc/sys/kernel/printk > >should take effect instantly. You _might_ be able to do this >remotely via ssh. Also possibly can do via magic sysrq + 0. > >(see: RHEL 6 Deployment Guide (rev 3.1 2011-05-19) Appendix C >pp.537-538) > >HTH, HAND, >-- >Charles Polisher > >___ >CentOS mailing list >CentOS@centos.org >https://lists.centos.org/mailman/listinfo/centos Tried it but did not work since I am not root... ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Getting hibernate to work on a new CentOS 7.2.1115 install
On Sun, Jun 12, 2016 at 10:46 AM, Ned Slider wrote: > > > On 12/06/16 16:45, Globe Trotter wrote: >> >> Hi, >> I am a new CentOS user (quite familiar with Fedora 1-23+) and I decided to >> try a new install of CentOS on a ASUS R503U. >> >> However, I can not get hibernate to work. I try: >> systemctl hibenaate >> and I get: >> Failed to execute operation: sleep verb not supported >> Btw, the problem does not go away with super-user. >> >> I was wondering how to get around this issue. I would like the abililty to >> hibernate and come back in the last state. >> Thanks! cat /sys/power/state cat /sys/power/disk The first should include 'disk' and the second should say enabled or some such. Note that hibernation is probably not supported by the CentOS kernel if this is on a UEFI computer with Secure Boot enabled (it's not supported by Fedora kernels) as it's a possible vector to defeat the point of Secure Boot. systemd does check to see if there's enough unused swap to fit Active(anon) mem into for hibernation, and if not then hibernation won't be possible. And yet another thing is that it's possible the initramfs isn't using resume= which is currently a problem on Fedora. So you might need to add this to the grub.cfg on the kernel command line, something like resume=/dev/VG/swap or wherever it is. If it's a /dev/sdXY, i.e. on a regular partition, then use UUID. -- Chris Murphy ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] scp via another server
Hi, This is fairly common. I would look into the use of a proxy command to do exactly what you ask. In addition, though not strictly necessary, I also would generally recommend rsync rather than scp*. Both of these are documented on my page here: http://www2.physics.ox.ac.uk/it-services/central-ssh-access Its got an Oxford Physics specific slant to it but hopefully its helpful. *I don't think rsync has any issue when the remote machine prints things either. Sean On 13 Jun 2016 7:26 pm, "H" wrote: > On June 12, 2016 8:51:42 PM CEST, cpol...@surewest.net wrote: > >On 2016-06-12 19:07, H wrote: > >> On 06/12/2016 05:21 PM, J Martin Rushton wrote: > >> > -BEGIN PGP SIGNED MESSAGE- > >> > Hash: SHA1 > >> > > >> > $ scp svr2:/path/to/source svr1:/path/to/dest > >> > > >> > You'll get twice the network traffic since the copy is running on > >your > >> > workstattoin (or whatever). > >> > > >> > On 12/06/16 15:40, H wrote: > >> > > I normally use ssh to log into a remote server, change directory > >> > > and then use scp from there to copy files from another remote > >> > > server to the first one. > >> > > > >> > > Now the first server has been hit by continuous error correction > >> > > messages from the ECC controller, all of which are corrected, and > >I > >> > > am unable to get a command line to issue the required commands to > >> > > change directory and then run scp from the other server. I have > >no > >> > > problems, however, getting into the first server - except for > >being > >> > > drowned by the error correction messages and the server seems to > >be > >> > > running "fine". > >> > > > >> > > Until I am able to get to the server and investigate, is it > >> > > possible to accomplish the above on a single command line, thus > >> > > avoiding seeing the error messages? I should add that both the > >> > > first and second server are set up to accept keys and not > >passwords > >> > > so at least I don't have to worry about that. > > > >Try changing kernel console log level to 0, possibly: > > > > echo '0 0 0 0' > /proc/sys/kernel/printk > > > >should take effect instantly. You _might_ be able to do this > >remotely via ssh. Also possibly can do via magic sysrq + 0. > > > >(see: RHEL 6 Deployment Guide (rev 3.1 2011-05-19) Appendix C > >pp.537-538) > > > >HTH, HAND, > >-- > >Charles Polisher > > > >___ > >CentOS mailing list > >CentOS@centos.org > >https://lists.centos.org/mailman/listinfo/centos > > Tried it but did not work since I am not root... > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Slow RAID Check/high %iowait during check after updgrade from CentOS 6.5 -> CentOS 7.2
On 2016-06-01 20:07, Kelly Lesperance wrote:
> Software RAID 10. Servers are HP DL380 Gen 8s, with 12x4 TB 7200 RPM drives.
>
> On 2016-06-01, 3:52 PM, "centos-boun...@centos.org on behalf of
> m.r...@5-cent.us"
> wrote:
>
> >Kelly Lesperance wrote:
> >> I did some additional testing - I stopped Kafka on the host, and kicked
> >> off a disk check, and it ran at the expected speed overnight. I started
> >> kafka this morning, and the raid check's speed immediately dropped down to
> >> ~2000K/Sec.
> >>
> >> I then enabled the write-back cache on the drives (hdparm -W1 /dev/sd*).
> >> The raid check is now running between 10K/Sec and 20K/Sec, and has
> >> been for several hours (it fluctuates, but seems to stay within that
> >> range). Write-back cache is NOT enabled for the drives on the hosts we
> >> haven't upgraded yet, but the speeds are similar (I kicked off a raid
> >> check on one of our CentOS 6 hosts as well, the window seems to be 15
> >> - 20K/Sec on that host).
Hi Kelly,
I hope this is relevant -- you might want to try the very most recent
kernel in git to see if your problem is fixed.
Best regards,
--
Charles Polisher
Date: Mon, 13 Jun 2016 15:51:19 +0200
From: Tomasz Majchrzak
To: linux-r...@vger.kernel.org
Subject: [PATCH] raid1/raid10: slow down resync if there is non-resync activity
pending
A performance drop of mkfs has been observed on RAID10 during resync
since commit 09314799e4f0 ("md: remove 'go_faster' option from
->sync_request()"). Resync sends so many IOs it slows down non-resync
IOs significantly (few times). Add a short delay to a resync. The
previous long sleep (1s) has proven unnecessary, even very short delay
brings performance right.
The change also applied to raid1. The problem has not been observed on
raid1, however it shares barriers code with raid10 so it might be an
issue for some setup too.
Suggested-by: NeilBrown
Link: http://lkml.kernel.org/r/20160609134555.ga9...@proton.igk.intel.com
Signed-off-by: Tomasz Majchrzak
---
drivers/md/raid1.c | 7 +++
drivers/md/raid10.c | 7 +++
2 files changed, 14 insertions(+)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 39fb21e..03c5349 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -2535,6 +2535,13 @@ static sector_t raid1_sync_request(struct mddev *mddev,
sector_t sector_nr,
return sync_blocks;
}
+ /*
+ * If there is non-resync activity waiting for a turn,
+ * then let it though before starting on this new sync request.
+ */
+ if (conf->nr_waiting)
+ schedule_timeout_uninterruptible(1);
+
/* we are incrementing sector_nr below. To be safe, we check against
* sector_nr + two times RESYNC_SECTORS
*/
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e3fd725..8a4791e 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2912,6 +2912,13 @@ static sector_t raid10_sync_request(struct mddev *mddev,
sector_t sector_nr,
max_sector > (sector_nr | chunk_mask))
max_sector = (sector_nr | chunk_mask) + 1;
+ /*
+ * If there is non-resync activity waiting for a turn,
+ * then let it though before starting on this new sync request.
+ */
+ if (conf->nr_waiting)
+ schedule_timeout_uninterruptible(1);
+
/* Again, very different code for resync and recovery.
* Both must result in an r10bio with a list of bios that
* have bi_end_io, bi_sector, bi_bdev set,
--
1.8.3.1
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Slow RAID Check/high %iowait during check after updgrade from CentOS 6.5 -> CentOS 7.2
On 06/13/2016 04:57 PM, cpol...@surewest.net wrote: you might want to try the very most recent kernel in git to see if your problem is fixed. Is there a specific change that is of interest? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
