Re: Amount of memory in buffers shown by the free command

2013-05-16 Thread Rob van der Heij
On 15 May 2013 17:00, Michael MacIsaac mike...@us.ibm.com wrote:


 Does anyone know why free shows a different amount of cached memory that
 /proc/meminfo? For example:


It's documented that Cached: in /proc/meminfo does not include swap cache,
while the value from free does. But there's still differences from what I
can tell, beyond the changes that happen in the second between the two
commands. If I had time, I would certainly look in the source where both
get their numbers and why they are different (which is more reliable than
google with stackoverflow :-).

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Putting devices offline automatically

2013-05-16 Thread Malcolm Beattie
Mauro Souza writes:
 Hi guys,

 I have a client with a peculiar problem. They have zVM 4 partitions,
 sharing the same LCU's, every partition sees every DASD, and each partition
 have its own range of disks, defined with Offline_at_IPL on SYSTEM CONFIG.
 They use this setup because some times they need to access in one partition
 a disk belonging to another.

 When this need arises, they issue a VARY ON 2345 and get the disk online,
 use it, copy something, VARY OFF 2345. Works fine.

 The problem: some channels are getting offline sometimes. We know that
 people are always messing with the cables, and from time to time one fiber
 or another gets loose, they fix, and so on. And when the device comes back
 online, every single DASD on that CHPID comes online too, ignoring the
 Offline_at_IPL statement. As it should, because Offline_at_IPL is just for
 IPL.

 We are thinking on a method and apparatus for getting those DASDs offline
 when the CHPID gets back to life. I already have a REXX (I just deleted a
 lot of lines of CPSYNTAX and added a few more) that parses SYSTEM CONFIG
 and looks if a given DASD is in the Offline_at_IPL range, and can put a
 DASD offline. I just could not make the exec run by itself (or by MAINT, or
 another CMS machine) every time a channel status changes.

 I tried to setup PROP, and it looks fine, except it doesn't react at all.
 My PROP RTABLE is configured to run my exec, but when the channel gets
 back, it does nothing. If I send the message by hand from MAINT, the exec
 runs, and puts the device offline if it is on Offline_at_IP range. I guess
 I will have to read everything about PROP again (I could find few
 documentation and examples), in case I have missed something.

 I saw the NOTACCEPTed statement for DEVICES on SYSTEM CONFIG, but looks
 like it will take the device offline forever, and we will need to bring it
 online sometimes.

 Does anyone have any idea for us?

NOTACCEPTED is reversible: provided you have#
FEATURES ENABLE SET_DEVICES in your SYSTEM CONFIG, you could try doing
 CP VARY OFFLINE rdev
 CP SET DEVICES NOTACCEPTED rdev

and see if that prevents the disappearance/reappearance of the
channel triggering it coming online again. The CP Commands and
Utilities Reference describes the behaviour as:
  NOTACCEPTed
  tells CP not to accept the specified device or devices when the
  device(s) is dynamically added to VM from another partition. When
  VM is running second level it will prevent a device(s) from
  being accepted when a device is attached to the virtual machine
  in which VM is running. If VM dynamically defines a device for
  its own partition the NOTACCEPTed designation is overridden.

and it's not completely clear to me which case is covered by
channel reappears. Worth a try though. Bringing it online again,
you should only need a
  CP VARY ONLINE rdev

CP still will retain some knowledge of the device though, so if that
doesn't work and you want CP to forget about it even more (though
still not entirely), you could try
 CP VARY OFFLINE rdev
 CP SET RDEVICE rdev CLEAR
 CP SET DEVICES NOTSENSED rdev
 CP SET DEVICES NOTACCEPTED rdev

After that lot, to bring it back with default DASD options you'll
want something like
 CP SET DEVICES SENSED rdev
 CP VARY ONLINE rdev

or, if you want non-default settings for the rdev's setting of
SHARED, EQID or MDC, you'll need instead an explicit
 CP SET RDEVICE rdev ... TYPE DASD ...
which includes your options, followed by
 CP VARY ONLINE rdev
(maybe preceded by
 CP SET DEVICES ACCEPTED rdev
 CP SET DEVICES SENSED rdev
for the sake of completeness).

--Malcolm

--
Malcolm Beattie
Mainframe Systems and Software Business, Europe
IBM UK

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Missing lv

2013-05-16 Thread Neale Ferguson
I used system-config-lvm to remove a lv “vg_rh62gfs/vg_swap”. It appeared to go 
ok and after zipling I rebooted only to get:

dracut: Scanning devices dasda1 dasdb1 dasdc1  for LVM logical volumes 
vg_rh62gfs/lv_root vg_rh62gfs/lv_swap
dracut: Skipping clustered volume group vg_snatest
dracut: Skipping volume group vg_snatest
dracut: inactive '/dev/vg_rh62gfs/lv_boot' [500.00 MiB] inherit
dracut: inactive '/dev/vg_rh62gfs/lv_root' [2.12 GiB] inherit
dracut: inactive '/dev/vg_rh62gfs/opt' [488.00 MiB] inherit
dracut: One or more specified logical volume(s) not found.
dracut: Scanning devices dasda1 dasdb1 dasdc1  for LVM logical volumes 
vg_rh62gfs/lv_root vg_rh62gfs/lv_swap

I mounted the volumes on another system and did a scan to find where vg_swap 
was still specified. I couldn’t find any reference so I’m not sure why dracut 
wants to find it.

Any suggestions?

Neale

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Missing lv

2013-05-16 Thread Rick Troth
/etc/fstab?

On Thu, May 16, 2013 at 10:59 AM, Neale Ferguson ne...@sinenomine.net wrote:
 I used system-config-lvm to remove a lv “vg_rh62gfs/vg_swap”. It appeared to 
 go ok and after zipling I rebooted only to get:

 dracut: Scanning devices dasda1 dasdb1 dasdc1  for LVM logical volumes 
 vg_rh62gfs/lv_root vg_rh62gfs/lv_swap
 dracut: Skipping clustered volume group vg_snatest
 dracut: Skipping volume group vg_snatest
 dracut: inactive '/dev/vg_rh62gfs/lv_boot' [500.00 MiB] inherit
 dracut: inactive '/dev/vg_rh62gfs/lv_root' [2.12 GiB] inherit
 dracut: inactive '/dev/vg_rh62gfs/opt' [488.00 MiB] inherit
 dracut: One or more specified logical volume(s) not found.
 dracut: Scanning devices dasda1 dasdb1 dasdc1  for LVM logical volumes 
 vg_rh62gfs/lv_root vg_rh62gfs/lv_swap

 I mounted the volumes on another system and did a scan to find where vg_swap 
 was still specified. I couldn’t find any reference so I’m not sure why dracut 
 wants to find it.

 Any suggestions?

 Neale

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/



-- 
-- R;   

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Missing lv

2013-05-16 Thread Neale Ferguson
Nope

On 5/16/13 11:02 AM, Rick Troth r...@casita.net wrote:

 /etc/fstab?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


/dev/urandom issue that was fixed in suse kernel version 3.0.74

2013-05-16 Thread Will, Chris
We ran into this issue and are rolling out the fix provided by Novell.  Novell 
was telling us that it was due to a large number of ssh logins to a host but 
this does not always seem to be the case.  Anyone have a more definitive reason 
for what caused the error and how it was fixed?

Chris Will


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Amount of memory in buffers shown by the free command

2013-05-16 Thread Michael MacIsaac
Alex and Rob,

Thanks for the replies.

It looks like the buffers value shown by free on SLES is the the sum
of the Cached and SReclaimable values from /proc/meminfo/, while on
RHEL it is just Cached.

On SLES:
 # egrep '^Cached|^SRe' /proc/meminfo;free
Cached:   130336 kB
SReclaimable:  17576 kB
 total   used   free sharedbuffers cached
Mem:   1020416 318156 702260  0  11688 147912
...

On RHEL:
# egrep '^Cached|^SRe' /proc/meminfo;free
Cached:36668 kB
SReclaimable:  25828 kB
 total   used   free sharedbuffers cached
Mem:245772 234828  10944  0  95568  36668
...

Mike MacIsaac mikemac at-sign us.ibm.com

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Missing lv

2013-05-16 Thread Steffen Maier

Hi Neale,

On 05/16/2013 04:59 PM, Neale Ferguson wrote:

I used system-config-lvm to remove a lv “vg_rh62gfs/vg_swap”. It appeared to go 
ok and after zipling I rebooted only to get:

dracut: Scanning devices dasda1 dasdb1 dasdc1  for LVM logical volumes 
vg_rh62gfs/lv_root vg_rh62gfs/lv_swap
dracut: Skipping clustered volume group vg_snatest
dracut: Skipping volume group vg_snatest
dracut: inactive '/dev/vg_rh62gfs/lv_boot' [500.00 MiB] inherit
dracut: inactive '/dev/vg_rh62gfs/lv_root' [2.12 GiB] inherit
dracut: inactive '/dev/vg_rh62gfs/opt' [488.00 MiB] inherit
dracut: One or more specified logical volume(s) not found.
dracut: Scanning devices dasda1 dasdb1 dasdc1  for LVM logical volumes 
vg_rh62gfs/lv_root vg_rh62gfs/lv_swap

I mounted the volumes on another system and did a scan to find where
vg_swap was still specified. I couldn’t find any reference so I’m not
sure why dracut wants to find it.


Do you happen to have this in your kernel command line?:
rd_LVM_LV=vg_rh62gfs/lv_swap

One should only ever have dependencies for the root-fs on the dracut 
command line [1,2]. Swap does not belong to the root-fs dependencies; 
swap is only activated later on during the sysVinit process after the 
root-fs was already mounted by the initramfs.
Also, it might make dracut insist on finding and activating this 
particular LV and thus breaks when it's gone.


[1] https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_lvm
[2] 
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info.html#ap-s390info-Adding_DASDs-Persistently_setting_online-Part_of_root_file_system


HTH
Steffen

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Putting devices offline automatically

2013-05-16 Thread Mauro Souza
Hi Malcolm!

We tried the setup you suggested, and worked as we wanted it!

Thanks!

Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.


2013/5/16 Malcolm Beattie beatt...@uk.ibm.com

 Mauro Souza writes:
  Hi guys,
 
  I have a client with a peculiar problem. They have zVM 4 partitions,
  sharing the same LCU's, every partition sees every DASD, and each
 partition
  have its own range of disks, defined with Offline_at_IPL on SYSTEM
 CONFIG.
  They use this setup because some times they need to access in one
 partition
  a disk belonging to another.
 
  When this need arises, they issue a VARY ON 2345 and get the disk online,
  use it, copy something, VARY OFF 2345. Works fine.
 
  The problem: some channels are getting offline sometimes. We know that
  people are always messing with the cables, and from time to time one
 fiber
  or another gets loose, they fix, and so on. And when the device comes
 back
  online, every single DASD on that CHPID comes online too, ignoring the
  Offline_at_IPL statement. As it should, because Offline_at_IPL is just
 for
  IPL.
 
  We are thinking on a method and apparatus for getting those DASDs
 offline
  when the CHPID gets back to life. I already have a REXX (I just deleted a
  lot of lines of CPSYNTAX and added a few more) that parses SYSTEM CONFIG
  and looks if a given DASD is in the Offline_at_IPL range, and can put a
  DASD offline. I just could not make the exec run by itself (or by MAINT,
 or
  another CMS machine) every time a channel status changes.
 
  I tried to setup PROP, and it looks fine, except it doesn't react at all.
  My PROP RTABLE is configured to run my exec, but when the channel gets
  back, it does nothing. If I send the message by hand from MAINT, the exec
  runs, and puts the device offline if it is on Offline_at_IP range. I
 guess
  I will have to read everything about PROP again (I could find few
  documentation and examples), in case I have missed something.
 
  I saw the NOTACCEPTed statement for DEVICES on SYSTEM CONFIG, but looks
  like it will take the device offline forever, and we will need to bring
 it
  online sometimes.
 
  Does anyone have any idea for us?

 NOTACCEPTED is reversible: provided you have#
 FEATURES ENABLE SET_DEVICES in your SYSTEM CONFIG, you could try doing
  CP VARY OFFLINE rdev
  CP SET DEVICES NOTACCEPTED rdev

 and see if that prevents the disappearance/reappearance of the
 channel triggering it coming online again. The CP Commands and
 Utilities Reference describes the behaviour as:
   NOTACCEPTed
   tells CP not to accept the specified device or devices when the
   device(s) is dynamically added to VM from another partition. When
   VM is running second level it will prevent a device(s) from
   being accepted when a device is attached to the virtual machine
   in which VM is running. If VM dynamically defines a device for
   its own partition the NOTACCEPTed designation is overridden.

 and it's not completely clear to me which case is covered by
 channel reappears. Worth a try though. Bringing it online again,
 you should only need a
   CP VARY ONLINE rdev

 CP still will retain some knowledge of the device though, so if that
 doesn't work and you want CP to forget about it even more (though
 still not entirely), you could try
  CP VARY OFFLINE rdev
  CP SET RDEVICE rdev CLEAR
  CP SET DEVICES NOTSENSED rdev
  CP SET DEVICES NOTACCEPTED rdev

 After that lot, to bring it back with default DASD options you'll
 want something like
  CP SET DEVICES SENSED rdev
  CP VARY ONLINE rdev

 or, if you want non-default settings for the rdev's setting of
 SHARED, EQID or MDC, you'll need instead an explicit
  CP SET RDEVICE rdev ... TYPE DASD ...
 which includes your options, followed by
  CP VARY ONLINE rdev
 (maybe preceded by
  CP SET DEVICES ACCEPTED rdev
  CP SET DEVICES SENSED rdev
 for the sake of completeness).

 --Malcolm

 --
 Malcolm Beattie
 Mainframe Systems and Software Business, Europe
 IBM UK

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Missing lv

2013-05-16 Thread Mauro Souza
You should take a look on your initrd too. Maybe the lv_swap is still
referenced there.

Try recreating it to see if the ghost lv vanishes for good.

Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.


2013/5/16 Steffen Maier ma...@linux.vnet.ibm.com

 Hi Neale,


 On 05/16/2013 04:59 PM, Neale Ferguson wrote:

 I used system-config-lvm to remove a lv “vg_rh62gfs/vg_swap”. It appeared
 to go ok and after zipling I rebooted only to get:

 dracut: Scanning devices dasda1 dasdb1 dasdc1  for LVM logical volumes
 vg_rh62gfs/lv_root vg_rh62gfs/lv_swap
 dracut: Skipping clustered volume group vg_snatest
 dracut: Skipping volume group vg_snatest
 dracut: inactive '/dev/vg_rh62gfs/lv_boot' [500.00 MiB] inherit
 dracut: inactive '/dev/vg_rh62gfs/lv_root' [2.12 GiB] inherit
 dracut: inactive '/dev/vg_rh62gfs/opt' [488.00 MiB] inherit
 dracut: One or more specified logical volume(s) not found.
 dracut: Scanning devices dasda1 dasdb1 dasdc1  for LVM logical volumes
 vg_rh62gfs/lv_root vg_rh62gfs/lv_swap

 I mounted the volumes on another system and did a scan to find where
 vg_swap was still specified. I couldn’t find any reference so I’m not
 sure why dracut wants to find it.


 Do you happen to have this in your kernel command line?:
 rd_LVM_LV=vg_rh62gfs/lv_swap

 One should only ever have dependencies for the root-fs on the dracut
 command line [1,2]. Swap does not belong to the root-fs dependencies; swap
 is only activated later on during the sysVinit process after the root-fs
 was already mounted by the initramfs.
 Also, it might make dracut insist on finding and activating this
 particular LV and thus breaks when it's gone.

 [1] https://www.kernel.org/pub/**linux/utils/boot/dracut/**
 dracut.html#_lvmhttps://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_lvm
 [2] https://access.redhat.com/**site/documentation/en-US/Red_**
 Hat_Enterprise_Linux/6/html/**Installation_Guide/ap-**
 s390info.html#ap-s390info-**Adding_DASDs-Persistently_**
 setting_online-Part_of_root_**file_systemhttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ap-s390info.html#ap-s390info-Adding_DASDs-Persistently_setting_online-Part_of_root_file_system

 HTH
 Steffen

 Linux on System z Development

 IBM Deutschland Research  Development GmbH
 Vorsitzende des Aufsichtsrats: Martina Koederitz
 Geschäftsführung: Dirk Wittkopp
 Sitz der Gesellschaft: Böblingen
 Registergericht: Amtsgericht Stuttgart, HRB 243294


 --**--**--
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/**wlvindex?LINUX-390http://www.marist.edu/htbin/wlvindex?LINUX-390
 --**--**--
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Missing lv

2013-05-16 Thread Neale Ferguson
That was it Steffen. I did a find / grep looking for vg_swap so I thought
it'd pick up the zipl.conf but I must have messed up the command. In any
event, I got rid of it and re-ran zipl.

Note, that rd_LVM wasn't put in manually by me but as part of the
installation.

Many thanks... Neale

On 5/16/13 1:39 PM, Steffen Maier ma...@linux.vnet.ibm.com wrote:


 Do you happen to have this in your kernel command line?:
 rd_LVM_LV=vg_rh62gfs/lv_swap

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: /dev/urandom issue that was fixed in suse kernel version 3.0.74

2013-05-16 Thread Leland Lucius
On 5/16/2013 10:15 AM, Will, Chris wrote:
 We ran into this issue and are rolling out the fix provided by Novell.  
 Novell was telling us that it was due to a large number of ssh logins to a 
 host but this does not always seem to be the case.  Anyone have a more 
 definitive reason for what caused the error and how it was fixed?


The ssh thing is just a way to recreate the problem.  It's really just a matter 
of multiple simultaneous users of /dev/urandon and ssh was one way to do it.  I 
was able to recreate it with:

#!/bin/sh

for ((c=0; c  32; c++))
do
for ((i=0; i  256; i++))
do
dd if=/dev/urandom of=/dev/null bs=1 count=4096 /dev/null 21 
done
done

dd if=/dev/urandom of=/dev/null bs=1 count=1 21 | grep -q '0 bytes'  echo 
badness
exit

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


Re: Amount of memory in buffers shown by the free command

2013-05-16 Thread Suthammanont, Alex C
Mike  Rob,
That is not what I see at my end. Below are sample of RHEL 5.9 and RHEL 6.3.
In both cases, the number of cached from the 'free' command matches to the 
number of cached found in /proc/meminfo. Strange but true..

$ cat /etc/*se
Red Hat Enterprise Linux Server release 6.3 (Santiago)
$ egrep '^Cached|^SRe' /proc/meminfo;free
Cached:  2082876 kB
SReclaimable: 287328 kB
 total   used   free sharedbuffers cached
Mem:   39785363879060  99476  0 5514522082876
-/+ buffers/cache:12447322733804
Swap:  1199784   39201195864


$ cat /etc/*se
Red Hat Enterprise Linux Server release 5.9 (Tikanga)
$ egrep '^Cached|^SRe' /proc/meminfo;free
Cached:4940460 kB
 total   used   free sharedbuffers cached
Mem:  10290680   10013064 277616  0 7163724940460
-/+ buffers/cache:43562325934448
Swap:  2135672   83162127356

Alex Suthammanont


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Michael 
MacIsaac
Sent: Thursday, May 16, 2013 1:10 PM
To: LINUX-390@vm.marist.edu
Subject: Re: Amount of memory in buffers shown by the free command

Alex and Rob,

Thanks for the replies.

It looks like the buffers value shown by free on SLES is the the sum of the 
Cached and SReclaimable values from /proc/meminfo/, while on RHEL it is 
just Cached.

On SLES:
 # egrep '^Cached|^SRe' /proc/meminfo;free
Cached:   130336 kB
SReclaimable:  17576 kB
 total   used   free sharedbuffers cached
Mem:   1020416 318156 702260  0  11688 147912
...

On RHEL:
# egrep '^Cached|^SRe' /proc/meminfo;free
Cached:36668 kB
SReclaimable:  25828 kB
 total   used   free sharedbuffers cached
Mem:245772 234828  10944  0  95568  36668
...

Mike MacIsaac mikemac at-sign us.ibm.com

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit http://wiki.linuxvm.org/

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/