Re: SLES10 GA
I got it with Firefox 1.5.0.4 to my windows 2K pc. Took all day. Then another day to upload to Linux virtual server with FTP. Byte counts match but the md5sums do not. I haven't gotten any farther than that. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Yakov Dekel Sent: Wednesday, July 26, 2006 09:48 To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] SLES10 GA Look like you are using windows+MSIE. I had the same symptom. Firefox, on the other hand, dies after exactly 4GB. I guess the best option (yet) is Linux. Haven't tried it yet. Jacob Dekel www.mvsdasd.org -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of FOFI DOMENICO Sent: Wednesday, July 26, 2006 1:22 PM To: LINUX-390@VM.MARIST.EDU Subject: R: SLES10 GA Anyone else getting a 208 Mb file when downloading the DVD ISO image for SLES-10/z? Anyone has successfully downloaded (4.2 GB) the DVD ISO image for SLES-10/z? Domenico Fofi Sistemi e Tecnologie - Supporto Sistemistico Sogei S.p.A Via Mario Carucci, 99 - 00143 Roma Tel. +39 06 50252685 Cell. +39 335 7264295 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES10 GA
Look like you are using windows+MSIE. I had the same symptom. Firefox, on the other hand, dies after exactly 4GB. I guess the best option (yet) is Linux. Haven't tried it yet. Jacob Dekel www.mvsdasd.org -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of FOFI DOMENICO Sent: Wednesday, July 26, 2006 1:22 PM To: LINUX-390@VM.MARIST.EDU Subject: R: SLES10 GA Anyone else getting a 208 Mb file when downloading the DVD ISO image for SLES-10/z? Anyone has successfully downloaded (4.2 GB) the DVD ISO image for SLES-10/z? Domenico Fofi Sistemi e Tecnologie - Supporto Sistemistico Sogei S.p.A Via Mario Carucci, 99 - 00143 Roma Tel. +39 06 50252685 Cell. +39 335 7264295 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: STK robotics from Linux
Somehow I missed the original question, but in order to accomplish mounts to a z/OS controlled STK library (the z/OS software is called NCS), you need the Library Station component running under NCS/HSC on z/OS, and you need the software running on Linux to understand the NCS/Library Station/ACSLS API. Newer versions of TSM speak directly to LibStation, older versions need an add-on from Gresham Computing called EDT. As for other applications, as long as they habla the ACSLS API, they should work. Scott Ledbetter Sun/STK -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Tim Hare Sent: Wednesday, July 26, 2006 10:15 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: STK robotics from Linux STK has support for "open system" clients to talk to the z/OS host component to accomplish tape mounts. I believe it's called Library Station - and it may require an add-on to HSC as well. Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Swap size to Memory size...
On 7/26/06, David Boyes <[EMAIL PROTECTED]> wrote: If it's performing well, don't fix it. It isn't broken. 8-) Unless you think that it may take up too much real resources for doing what it does, and you're planning to run more Linux servers without upgrade of the hardware in the same ratio. ;-) Yeah, performance monitoring and capacity planning Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: MDISK vs DEDICATED DASD
>> >Negatives: >> >Lose hardware IOASSIST feature for non-dedicated volumes. Not as >> >important as it used to be, but still noticeable. >> That's gone anyway on a z9, right? >Not sure, but I think so. Most of the other assorted hardware assists >are gone on the z9, so it wouldn't surprise me. >Then again, if you have a z9, you probably don't much care. 8-) Found my systems assurance guide, and yes, it is gone. You'd think I'd clearly remember that having sat through 3 of those meetings, yawn :) And right, they're so fast, who cares... Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." > >Negatives: > >Lose hardware IOASSIST feature for non-dedicated volumes. Not as > >important as it used to be, but still noticeable. > That's gone anyway on a z9, right? > Marcy Cortes Not sure, but I think so. Most of the other assorted hardware assists are gone on the z9, so it wouldn't surprise me. Then again, if you have a z9, you probably don't much care. 8-) -- db -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Swap size to Memory size...
> > If it's performing well, don't fix it. It isn't broken. 8-) > Unless you think that it may take up too much real resources for doing > what it does, ... in which case, it is _not_ performing well, and thus needs fixing. -- db -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: MDISK vs DEDICATED DASD
> >Negatives: > >Lose hardware IOASSIST feature for non-dedicated volumes. Not as > >important as it used to be, but still noticeable. > That's gone anyway on a z9, right? > Marcy Cortes Not sure, but I think so. Most of the other assorted hardware assists are gone on the z9, so it wouldn't surprise me. Then again, if you have a z9, you probably don't much care. 8-) -- db -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wednesday, 07/26/2006 at 02:55 EST, J Leslie Turriff <[EMAIL PROTECTED]> wrote: > Okay. I may be wrong, but it seems to me that the majority of Linux > applications (probably excepting database packages and such) rely on the > filesystem to eventually get their data to disk without them doing > anything besides open, write and close operations. And the circle is closed. Hence this entire thread/rant about shutting down servers while you are flashcopying or otherwise performing external physical backups. If you know what you and the application are doing, take a live backup. If you don't, don't. If the application provides you with a set of backup functions, use them. Oh, and the point that actually started the whole thing: Test your backups. You should already be doing that in your DR tests, but if you change your processes, re-test. "There's a hole in my bucket, dear Liza, dear Liza" ;-) Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wednesday, 07/26/2006 at 02:20 AST, David Kreuter <[EMAIL PROTECTED]> wrote: > including ESTABLISH, QUERY and WITHDRAW ala ickdsf on z/OS? > will ickdsf on z/vm be changed to support these functions? I give an inch and you want a mile! :-) We will, among other things, be adding a QUERY capability for convenience. As far as ICKDSF goes, you can establish flashcopy relationships among your minidisks as long as they are on the same controller. You may need to order service for DSF to bring it's functionality up the that documented in the -30 level of the manual. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
Okay. I may be wrong, but it seems to me that the majority of Linux applications (probably excepting database packages and such) rely on the filesystem to eventually get their data to disk without them doing anything besides open, write and close operations. J. Leslie Turriff VM Systems Programmer Central Missouri State University Room 400 Ward Edwards Building Warrensburg MO 64093 660-543-4285 660-580-0523 [EMAIL PROTECTED] >>>[EMAIL PROTECTED] 07/26/06 2:04 pm >>> On Wednesday, 07/26/2006 at 01:27 EST, J Leslie Turriff <[EMAIL PROTECTED]> wrote: >Okay, now, wait; are you saying that the storage device _does_ have a >mechanism for communicating with the Linux filesystem to determine what >filesystem pages are still cached in main storage and have not yet been >commited to external storage? No. I'm saying that an application that closes or flushes all of its open files and then tells the filesystem "commit the filesystem to disk" (e.g. sync) is then at a known point with respect to the dasd. It is free at that point to kick off a flashcopy via some command or utility and start running again. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 !DSPAM:32225,44c7bdcf88571709617740! -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: One last call for chairs.....
On Tuesday 25 July 2006 14:39, Martha McConaghy wrote: >I'm sure you are all sick of these notes by now, so I really hope this will >be the last one (at least for this SHARE). We still have lots of good >sessions available that need the support of a good chairperson. There are >Linux sessions, there are VM sessionssomething for everyone. I'm a bit slow getting my schedule planned for Baltimore, so I hadn't responded to your first request. Here's my list of the sessions I could chair: 9214Mon 11:00a sudo - Secure and Convenient 9115Tue 01:30p VM Performance Introduction 9257Tue 03:00p FCP Channel Virtualization in a Linux Environment 9206Tue 04:30p Cloning Linux Images under z/VM 9150Wed 08:00a CSE for High Availability and System Management 9278Wed 01:30p Levanta - Managing Linux on z/VM (and Intel) 9266Wed 03:00p CPU Accounting for Linux Virtual Servers 9219Fri 09:30a Easy z/VM Linux Guest System Deployment and Management With IBM Director >So, if you are coming to Baltimore, pick a session and volunteer to chair! >We'll buy you a drink at SCIDSppsssI mean the "post session, >pre-sleep group socialization and free food hour" (the new politically >correct SCIDS). Does this really come with free drinks? :-) Well, heck! If it's one free drink per chaired session, that should just about put me under the table. :-) See ya there! - MacK. - Edmund R. MacKenty Software Architect Rocket Software, Inc. Newton, MA USA -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Missing e2fsadm
>From what I recall, e2fsadm was an LVM1 command. It's not shipped on systems with LVM2. You can duplicate it's function by: umount /path/to/filesystem lvextend e2fsck -f /dev/volgroup/lvname resize2fs /dev/volgroup/lvname mount the file system Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Jim Chappell Sent: Wednesday, July 26, 2006 1:47 PM To: LINUX-390@VM.MARIST.EDU Subject: Missing e2fsadm I'm running SLES 9 64bit just a playground for now (no maintenance)...And right now I'm playing with LVM but I don't appear to have command e2fsadm. Anyone want to guess what I've done wrong? Jim Chappell -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: MDISK vs DEDICATED DASD
>Negatives: >Lose hardware IOASSIST feature for non-dedicated volumes. Not as >important as it used to be, but still noticeable. That's gone anyway on a z9, right? Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: MDISK vs DEDICATED DASD
Thanks to both John and David for their insight. I believe I will go with mini disks and turn off the MDCACHE. Thanks again. Ryan Stewart Indian River Community College -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Wednesday, July 26, 2006 2:26 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: MDISK vs DEDICATED DASD > Wondering if anyone can tell me whether or not there is an advantage or > a reason or a disadvantage to using MDISKs for Linux servers if I intend > to turn off the MDC, verses using dedicated disks. I intend to use the > entire disks and not split them up. Some things that come to my mind immediately: Positives for minidisks: Much simpler creation of 2nd level test systems -- copy to new volume/mdisk for 2nd level and don't mess up real volsers Much simpler DR -- can be restored to replacement disks w/o relabeling or disturbing existing volume naming scheme. Minidisks are accessible from other userids (dedicated devices are not accessible from other ids) for dumping, etc (cf other ongoing discussion on backups). MDC for minidisks can be trivially re-enabled non-disruptively if you need/want it. Negatives: Lose hardware IOASSIST feature for non-dedicated volumes. Not as important as it used to be, but still noticeable. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wednesday, 07/26/2006 at 01:27 EST, J Leslie Turriff <[EMAIL PROTECTED]> wrote: > Okay, now, wait; are you saying that the storage device _does_ have a > mechanism for communicating with the Linux filesystem to determine what > filesystem pages are still cached in main storage and have not yet been > commited to external storage? No. I'm saying that an application that closes or flushes all of its open files and then tells the filesystem "commit the filesystem to disk" (e.g. sync) is then at a known point with respect to the dasd. It is free at that point to kick off a flashcopy via some command or utility and start running again. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Missing e2fsadm
For those who prefers the command line utilities, there is a good howto : http://www.tldp.org/HOWTO/LVM-HOWTO/ The "common tasks" section should be read first for people who don't like docs :-) These commands are part of the LVM2 package under SLES. On 7/26/06, Ranga Nathan <[EMAIL PROTECTED]> wrote: Jim Chappell wrote: > I'm running SLES 9 64bit just a playground for now (no > maintenance)...And right now I'm playing with LVM but I don't appear to > have command e2fsadm. > I dont have it either and I never felt the need to use it. I cheated. I used YaST for all LVM management. The only thing I have to constantly remind myself is, to be safe, always do a "mkinitrd" and "zipl" to make sure that the LVM comes up at next boot time. Looking at http://linux.about.com/library/cmd/blcmdl8_e2fsadm.htm , I see that e2fsadm allow you to resize mounted file systems as well. That is definitely a plus. resize2fs requires unmounting file systems. BTW, it would be nice to have some polymorphism here across file systems - same command that recognizes the file system and issue different commands. Perhaps there is a shell script to do it? > > Anyone want to guess what I've done wrong? > > > Jim Chappell > 503 745-7841 > 503 349-5603(Cell) > [EMAIL PROTECTED] > > "Not everything that can be counted counts, and not everything that > counts can be counted." - Albert Einstein > > "Never trust a computer you can lift" > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > -- __ Ranga Nathan Work: 714-442-7591 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
Okay, now, wait; are you saying that the storage device _does_ have a mechanism for communicating with the Linux filesystem to determine what filesystem pages are still cached in main storage and have not yet been commited to external storage? J. Leslie Turriff VM Systems Programmer Central Missouri State University Room 400 Ward Edwards Building Warrensburg MO 64093 660-543-4285 660-580-0523 [EMAIL PROTECTED] >>>[EMAIL PROTECTED] 07/26/06 11:50 am >>> On Wednesday, 07/26/2006 at 10:33 EST, J Leslie Turriff <[EMAIL PROTECTED]> wrote: >Sounds to me, then, like the use of the >snapshot/mirror/peer-to-peer copy features of storage devices e.g. >Shark, SATABeast, etc. are currently dangerous to use with Linux >filesystems. They would need to be able to coordinate their activities >with the filesystem lock/unlock components of the kernel to be made >safe? No, they are not "currently dangerous to use with Linux". The snapshot/flashcopy features provide a point-in-time consistent view of an entire device or range of blocks/cylinders. In a "normal" track-by-track read, data on the device can change while you're reading. You're right, however, and as we've been discussing, that these features can be misused or misinterpreted to provide an -consistent view of the data. They don't do that. That applies to any operating system, not just Linux. And it's not the lock/unlock features of a filesystem that are important. Instead, the application must be able to exert control on the filesystem in such a way that it *knows* that all [relevant] data has been committed to disk and can say "OK. Now is a good time to take that backup." Properly used, these features can drastically reduce the amount of down time needed to perform application-consistent backups. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 !DSPAM:32225,44c79d9988571674117836! -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: MDISK vs DEDICATED DASD
> Wondering if anyone can tell me whether or not there is an advantage or > a reason or a disadvantage to using MDISKs for Linux servers if I intend > to turn off the MDC, verses using dedicated disks. I intend to use the > entire disks and not split them up. Some things that come to my mind immediately: Positives for minidisks: Much simpler creation of 2nd level test systems -- copy to new volume/mdisk for 2nd level and don't mess up real volsers Much simpler DR -- can be restored to replacement disks w/o relabeling or disturbing existing volume naming scheme. Minidisks are accessible from other userids (dedicated devices are not accessible from other ids) for dumping, etc (cf other ongoing discussion on backups). MDC for minidisks can be trivially re-enabled non-disruptively if you need/want it. Negatives: Lose hardware IOASSIST feature for non-dedicated volumes. Not as important as it used to be, but still noticeable. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
including ESTABLISH, QUERY and WITHDRAW ala ickdsf on z/OS? will ickdsf on z/vm be changed to support these functions? David Yes, the CP FLASHCOPY command is one of those asynchronous commands. But take heart! We are busily improving it, making it more suitable for use in scripts. (And adding function to it while we're at it.) Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Swap size to Memory size...
In the days of old when swap size was swap size and where everything in
memory had a copy in the swap space, that space actually set the limit for
"real space". In effect, virtual space was exactly the size of the swap
space, so you'd set that size to some increment over the real memory size.
Some folks like a 2:1 overcommitment ratio where the swap space is twice
the size of real memory (let's leave out the size of the OS and buffer
cache, OK?)
With demand paging and block loading, the old rules of thumb for sizing
swap space need to be re-thought. In effect, for the executable ("pure"
code, in the "code segment") code, the actual file being executed is part
of the paging space.
First off, your workload will have a point where it will thrash at a
specific overcommitment ratio. This crossover point is specific to a given
workload.
Total virtual size in a paging system is the real memory + paging space
(and, for linux: + size of code segments of all executing programs).
While you are likely under some pressure to shring your Linux instance's
memory footprint, you need to take a look at how much memory is actually in
use and for what-- i.e. real data (what I recall AIX referring to as
"computational space") and I/O buffers.
Additionally-- and here's one of the debatable points-- making your
instance bigger and doing away with paging space entirely may be very
tempting, allowing z/VM to manage actual paging, except, of course, that
you then have to tune Linux's buffer allocation sizing to minimize the
space allocated (as it currently stands, Linux will, if the workload is
"right", often try to use all of the memory not busy carrying a program's
code or data segments as I/O buffer space).
Otherwise, it strikes me that this is one of those subjects that can drive
yet another religious war...
John R. Campbell, Speaker to Machines (GNUrd) (813) 356-5322 (t/l 697)
Adsumo ergo raptus sum
MacOS X: Because making Unix user-friendly was easier than debugging
Windows.
Red Hat Certified Engineer (#803004680310286)
IBM Certified: IBM AIX 4.3 System Administration, System Support
- Forwarded by John Campbell/Tampa/IBM on 07/26/06 12:48 PM -
Brian France
<[EMAIL PROTECTED]>
Sent by: Linux on To
390 Port LINUX-390@VM.MARIST.EDU
<[EMAIL PROTECTED] cc
IST.EDU>
Subject
[LINUX-390] Swap size to Memory
07/26/06 11:39 AM size...
Please respond to
Linux on 390 Port
<[EMAIL PROTECTED]
IST.EDU>
Folks,
I have an image that is 1280m. It's swap space is 464m. Is that a
good ratio? The image has chewed up according to Perftoolkit 75% of
it. I was thinking a bigger swap space as opposed to more memory
which is what I being pressured to do. Response times seems great.
This image is running DB2 and Tamino (SAG data base) and some other
things. I just was sure if there was a good rule of thumb to follow
regarding image size and swap space. THANX!!!
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/Sysarc
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
[EMAIL PROTECTED]
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wednesday, 07/26/2006 at 01:59 AST, Michael MacIsaac/Poughkeepsie/[EMAIL PROTECTED] wrote: > The z/VM FLASHCOPY command can give a return code of 0 and then *fail* > later asynchronously. It is difficult to trap in REXX (for a mere mortal > like myself). And it will fail reliably (and asynchronously) if you queue > up too much work to the Shark/DSx000. This behavior is not well suited to > scripting :(( As such we had to pull back in a few cases on FLASHCOPY in > "The Virtualization Cookbook". Yes, the CP FLASHCOPY command is one of those asynchronous commands. But take heart! We are busily improving it, making it more suitable for use in scripts. (And adding function to it while we're at it.) Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Missing e2fsadm
Jim Chappell wrote: I'm running SLES 9 64bit just a playground for now (no maintenance)...And right now I'm playing with LVM but I don't appear to have command e2fsadm. I dont have it either and I never felt the need to use it. I cheated. I used YaST for all LVM management. The only thing I have to constantly remind myself is, to be safe, always do a "mkinitrd" and "zipl" to make sure that the LVM comes up at next boot time. Looking at http://linux.about.com/library/cmd/blcmdl8_e2fsadm.htm , I see that e2fsadm allow you to resize mounted file systems as well. That is definitely a plus. resize2fs requires unmounting file systems. BTW, it would be nice to have some polymorphism here across file systems - same command that recognizes the file system and issue different commands. Perhaps there is a shell script to do it? Anyone want to guess what I've done wrong? Jim Chappell 503 745-7841 503 349-5603(Cell) [EMAIL PROTECTED] "Not everything that can be counted counts, and not everything that counts can be counted." - Albert Einstein "Never trust a computer you can lift" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- __ Ranga Nathan Work: 714-442-7591 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 begin:vcard fn:Ranga Nathan n:Nathan;Ranga email;internet:[EMAIL PROTECTED] tel;work:714-442-7591 version:2.1 end:vcard
Re: Swap size to Memory size...
On Jul 26, 2006, at 8:39 AM, Brian France wrote: Folks, I have an image that is 1280m. It's swap space is 464m. Is that a good ratio? The image has chewed up according to Perftoolkit 75% of it. I was thinking a bigger swap space as opposed to more memory which is what I being pressured to do. Response times seems great. This image is running DB2 and Tamino (SAG data base) and some other things. I just was sure if there was a good rule of thumb to follow regarding image size and swap space. THANX!!! I like to have swap as big as physical memory, or on some servers twice its size. However, what I'd really recommend: make your image big enough that it's just barely swapping. Then define multiple tiers of swap. The highest (lowest? I can never remember how swap priority works without the man page)--anyway, the one you swap to first should be on VDISK or a saved segment mapped into your address space, and should be somewhere around 25% of physical memory--and beyond that, have real DASD for swap backing. Sine Nomine has a free program called SWAPGEN that you can download that does all the work of allocating and writing a swap signature to VDISK during your initial CMS IPL of the guest, which makes that approach very easy (although it's a bit slower than saved-segment- mapped swap, I think). In general. Your mileage may vary, this is only a rule of thumb and depends on your actual workload, etc., etcbut that's where I'd start. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
> Unless I am terribly misinformed, it *is* an atomic operation for the > operating system. Even though from a storage management point of view > it may take some time. The z/VM FLASHCOPY command can give a return code of 0 and then *fail* later asynchronously. It is difficult to trap in REXX (for a mere mortal like myself). And it will fail reliably (and asynchronously) if you queue up too much work to the Shark/DSx000. This behavior is not well suited to scripting :(( As such we had to pull back in a few cases on FLASHCOPY in "The Virtualization Cookbook". "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: MDISK vs DEDICATED DASD
So for backup purposes it is a good idea to use the minidisks (with the cache turned off). Something like this: MDISK 200 3390 001 3338 lnx710 MR ? Thanks, Ryan Stewart Indian River Community College -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Romanowski, John (OFT) Sent: Wednesday, July 26, 2006 1:31 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: MDISK vs DEDICATED DASD Not to throw you a curve but you could sort of do both at the same time: In the guest's USER DIRECT definition, instead of DEDICATE vdev rdev Which would dedicate the whole rdev dasd device to the guest but then your backup utility can't LINK a DEDICATE-d device for backups, You could instead do MDISK vdev DEVNO rdev That way the guest has the whole device independent of its volid (like DEDICATE) plus your backup utility can LINK the vdev MDISK for backup/restores. To protect CP at IPL-time from the potential for duplicate volid issues you would have all the DEVNO rdev's OFFLINE_AT_IPL and have AUTOLOG1's PROFILE EXEC VARY ON rdevx-rdevy This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Stewart Sent: Wednesday, July 26, 2006 1:08 PM To: LINUX-390@VM.MARIST.EDU Subject: MDISK vs DEDICATED DASD Hi all, Wondering if anyone can tell me whether or not there is an advantage or a reason or a disadvantage to using MDISKs for Linux servers if I intend to turn off the MDC, verses using dedicated disks. I intend to use the entire disks and not split them up. Thanks in advance. Ryan Stewart Systems Programmer Indian River Community College [EMAIL PROTECTED] 772-462-7310 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Missing e2fsadm
I'm running SLES 9 64bit just a playground for now (no maintenance)...And right now I'm playing with LVM but I don't appear to have command e2fsadm. Anyone want to guess what I've done wrong? Jim Chappell 503 745-7841 503 349-5603(Cell) [EMAIL PROTECTED] "Not everything that can be counted counts, and not everything that counts can be counted." - Albert Einstein "Never trust a computer you can lift" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Swap size to Memory size...
> I have an image that is 1280m. It's swap space is 464m. Is that a > good ratio? The image has chewed up according to Perftoolkit 75% of > it. I was thinking a bigger swap space as opposed to more memory > which is what I being pressured to do. Response times seems great. > This image is running DB2 and Tamino (SAG data base) and some other > things. I just was sure if there was a good rule of thumb to follow > regarding image size and swap space. THANX!!! If the machine is consistently using 75% of its swap, you probably should think about increasing the size of the virtual machine a little bit, but you're right that in general giving it more swap is a much better idea if performance is not impacted. I try to size for about 25% of swap maximum, but I'm a little conservative on that. I think it depends on the behavior of the application and how often it needs to swap. How frequently is it swapping? If it's performing well, don't fix it. It isn't broken. 8-) David Boyes Sine Nomine Associates -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: MDISK vs DEDICATED DASD
Not to throw you a curve but you could sort of do both at the same time: In the guest's USER DIRECT definition, instead of DEDICATE vdev rdev Which would dedicate the whole rdev dasd device to the guest but then your backup utility can't LINK a DEDICATE-d device for backups, You could instead do MDISK vdev DEVNO rdev That way the guest has the whole device independent of its volid (like DEDICATE) plus your backup utility can LINK the vdev MDISK for backup/restores. To protect CP at IPL-time from the potential for duplicate volid issues you would have all the DEVNO rdev's OFFLINE_AT_IPL and have AUTOLOG1's PROFILE EXEC VARY ON rdevx-rdevy This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Stewart Sent: Wednesday, July 26, 2006 1:08 PM To: LINUX-390@VM.MARIST.EDU Subject: MDISK vs DEDICATED DASD Hi all, Wondering if anyone can tell me whether or not there is an advantage or a reason or a disadvantage to using MDISKs for Linux servers if I intend to turn off the MDC, verses using dedicated disks. I intend to use the entire disks and not split them up. Thanks in advance. Ryan Stewart Systems Programmer Indian River Community College [EMAIL PROTECTED] 772-462-7310 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Swap size to Memory size...
Rob van der Heij wrote: On 7/26/06, Brian France <[EMAIL PROTECTED]> wrote: I have an image that is 1280m. It's swap space is 464m. Is that a good ratio? The image has chewed up according to Perftoolkit 75% of it. I was thinking a bigger swap space as opposed to more memory which is what I being pressured to do. Little rules of thumb or golden ratio. The total of swap space and 'real' memory relates to how much virtual memory Linux can hand out. If the sum of that is too low then you get Out-of-Memory terminations. Whether the ratio is 1:1 or 10:1. The algorithm for allocating swap space makes it use fresh pages rather than re-use old ones. This means that the "used" portion will grow until all has been used. You can prevent that by using multiple vdisks for swapping. When they have different priority you force Linux to reuse free space in the first before using fresh pages in the second. You should compare the internal memory measurements in Linux with the VM side to draw conclusions. When considering z/VM VDISKs for Linux swap you should refer to: http://www.vm.ibm.com/perf/tips/linuxper.html Specifically note VDISK advantage only when z/VM has plenty of REAL storage available, and that idle Linux guests can prevent the z/VM page stealing alg. from working efficiently (Steals from other guests first.) Mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
MDISK vs DEDICATED DASD
Hi all, Wondering if anyone can tell me whether or not there is an advantage or a reason or a disadvantage to using MDISKs for Linux servers if I intend to turn off the MDC, verses using dedicated disks. I intend to use the entire disks and not split them up. Thanks in advance. Ryan Stewart Systems Programmer Indian River Community College [EMAIL PROTECTED] 772-462-7310 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wednesday, 07/26/2006 at 10:33 EST, J Leslie Turriff <[EMAIL PROTECTED]> wrote: > Sounds to me, then, like the use of the > snapshot/mirror/peer-to-peer copy features of storage devices e.g. > Shark, SATABeast, etc. are currently dangerous to use with Linux > filesystems. They would need to be able to coordinate their activities > with the filesystem lock/unlock components of the kernel to be made > safe? No, they are not "currently dangerous to use with Linux". The snapshot/flashcopy features provide a point-in-time consistent view of an entire device or range of blocks/cylinders. In a "normal" track-by-track read, data on the device can change while you're reading. You're right, however, and as we've been discussing, that these features can be misused or misinterpreted to provide an *application*-consistent view of the data. They don't do that. That applies to any operating system, not just Linux. And it's not the lock/unlock features of a filesystem that are important. Instead, the application must be able to exert control on the filesystem in such a way that it *knows* that all [relevant] data has been committed to disk and can say "OK. Now is a good time to take that backup." Properly used, these features can drastically reduce the amount of down time needed to perform application-consistent backups. Alan Altmark z/VM Development IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Swap size to Memory size...
On 7/26/06, Brian France <[EMAIL PROTECTED]> wrote: I have an image that is 1280m. It's swap space is 464m. Is that a good ratio? The image has chewed up according to Perftoolkit 75% of it. I was thinking a bigger swap space as opposed to more memory which is what I being pressured to do. Little rules of thumb or golden ratio. The total of swap space and 'real' memory relates to how much virtual memory Linux can hand out. If the sum of that is too low then you get Out-of-Memory terminations. Whether the ratio is 1:1 or 10:1. The algorithm for allocating swap space makes it use fresh pages rather than re-use old ones. This means that the "used" portion will grow until all has been used. You can prevent that by using multiple vdisks for swapping. When they have different priority you force Linux to reuse free space in the first before using fresh pages in the second. You should compare the internal memory measurements in Linux with the VM side to draw conclusions. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On 7/26/06, Mark Perry <[EMAIL PROTECTED]> wrote: One point not mentioned yet, is that FLASHCOPY is an asynchronous process. You can start a FLASHCOPY operation and it *can* return an error status asynchronously. 90+% of the time this is not apparent, the request is made and the Shark goes happily on its way. However if the request that is queued within the Shark has to be terminated (Resource shortages, target volume errors etc.) then beware! Unless I am terribly misinformed, it *is* an atomic operation for the operating system. Even though from a storage management point of view it may take some time. And to maintain the illusion the device needs resources (e.g. cache, extra disk space, etc). The same applies to freezing the file system in Linux as suggested. If freezing means that dirty pages are held back until the freeze is over, then it will increase the demand for memory in the server. If the server is large enough this process would increase the working set size, but not worse than otherwise because page cache would be used anyway. Using snapshot on the DASD subsystem means you can shorten the time that Linux needs to hold its breath, and thus limit the amount of data to be held up. The alternative (file level backup inside Linux) will fill the page cache with meta data for the entire file system (rather than the content that changed during backup). Which is worse depends on your situation. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: STK robotics from Linux
STK has support for "open system" clients to talk to the z/OS host component to accomplish tape mounts. I believe it's called Library Station - and it may require an add-on to HSC as well. Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
J Leslie Turriff wrote: > Sounds to me, then, like the use of the > snapshot/mirror/peer-to-peer copy features of storage devices e.g. > Shark, SATABeast, etc. are currently dangerous to use with Linux > filesystems. They would need to be able to coordinate their activities > with the filesystem lock/unlock components of the kernel to be made > safe? Exactly, yes. cheers, Carsten -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
- Start Original Message - Sent: Wed, 26 Jul 2006 10:33:32 -0500 From: J Leslie Turriff <[EMAIL PROTECTED]> To: LINUX-390@VM.MARIST.EDU Subject: Re: Bad Linux backups > Sounds to me, then, like the use of the > snapshot/mirror/peer-to-peer copy features of storage devices e.g. > Shark, SATABeast, etc. are currently dangerous to use with Linux > filesystems. They would need to be able to coordinate their activities > with the filesystem lock/unlock components of the kernel to be made > safe? One point not mentioned yet, is that FLASHCOPY is an asynchronous process. You can start a FLASHCOPY operation and it *can* return an error status asynchronously. 90+% of the time this is not apparent, the request is made and the Shark goes happily on its way. However if the request that is queued within the Shark has to be terminated (Resource shortages, target volume errors etc.) then beware! Mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Swap size to Memory size...
Folks, I have an image that is 1280m. It's swap space is 464m. Is that a good ratio? The image has chewed up according to Perftoolkit 75% of it. I was thinking a bigger swap space as opposed to more memory which is what I being pressured to do. Response times seems great. This image is running DB2 and Tamino (SAG data base) and some other things. I just was sure if there was a good rule of thumb to follow regarding image size and swap space. THANX!!! Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/Sysarc Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
Sounds to me, then, like the use of the snapshot/mirror/peer-to-peer copy features of storage devices e.g. Shark, SATABeast, etc. are currently dangerous to use with Linux filesystems. They would need to be able to coordinate their activities with the filesystem lock/unlock components of the kernel to be made safe? J. Leslie Turriff VM Systems Programmer Central Missouri State University Room 400 Ward Edwards Building Warrensburg MO 64093 660-543-4285 660-580-0523 [EMAIL PROTECTED] >>>[EMAIL PROTECTED] 07/26/06 9:04 am >>> On Wed, Jul 26, 2006 at 02:28:53PM +0200, Carsten Otte wrote: >Very interresting indeed. This pointed me to reading the >lockfs/unlockfs semantics in Linux, and I think I need to withdraw my >statement regarding flashcopy snapshots: because of the fact that >there is no lockfs/unlockfs interaction when doing flashcopy, and >because of dirty pages in the page cache during snapshot, flashcopy >will not generate a consistent snapshot. Therefore, using flashcopy on >an active volume from outside Linux is _not_ suitable for backup purposes. > >The only feasible way to get a consistent snapshot is to use >dm-snapshot from within Linux. This snapshot copy can later on be used >with a backup feature outside Linux. If you use xfs you can also put the filesystem in frozen state from userspace with the xfs_freeze utility. I know of inhouse backup tools at various companies that make use of this feature. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 !DSPAM:32225,44c776f188571486219204! -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wed, Jul 26, 2006 at 02:28:53PM +0200, Carsten Otte wrote: > Very interresting indeed. This pointed me to reading the > lockfs/unlockfs semantics in Linux, and I think I need to withdraw my > statement regarding flashcopy snapshots: because of the fact that > there is no lockfs/unlockfs interaction when doing flashcopy, and > because of dirty pages in the page cache during snapshot, flashcopy > will not generate a consistent snapshot. Therefore, using flashcopy on > an active volume from outside Linux is _not_ suitable for backup purposes. > > The only feasible way to get a consistent snapshot is to use > dm-snapshot from within Linux. This snapshot copy can later on be used > with a backup feature outside Linux. If you use xfs you can also put the filesystem in frozen state from userspace with the xfs_freeze utility. I know of inhouse backup tools at various companies that make use of this feature. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
- Start Original Message - Sent: Wed, 26 Jul 2006 11:49:45 +0200 From: Christoph Hellwig <[EMAIL PROTECTED]> To: LINUX-390@VM.MARIST.EDU Subject: Re: Bad Linux backups > On Tue, Jul 25, 2006 at 01:22:53PM +0200, Mark Perry wrote: > > I believe that several DB systems offer direct/raw I/O to avoid Linux cache > > problems, and that journaling filesystems, although by default only journal > > meta-data, offer mount options to journal data too. This of course comes at > > a performance price, though Hans Reiser did claim that the new Resier4 FS > > will journal data without the previous performance penalties. > > Journalled filesystems only journal buffered I/O. Direct I/O means you > do direct dma operations from the storage controller to the user address > space. It's physically impossible to journal. I agree, I did not mean to connect direct I/O and journalling. I was merely commenting on features that are available to assist in ensuring data integrity on disk. Mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: R: SLES10 GA
I downloaded it on both a Linux system and a Windows XP system at full size with no problem. Paul Giordano Technical Sales Specialist - Linux zSeries e-business Solutions Technical Sales, Americas (312) 529-1347 (630) 207-9435 (cell) email: [EMAIL PROTECTED] Check http://www.ibm.com/linux for the latest in Linux news and information FOFI DOMENICO <[EMAIL PROTECTED]> Sent by: Linux on 390 Port 07/26/2006 05:21 AM Please respond to Linux on 390 Port To LINUX-390@VM.MARIST.EDU cc Subject R: SLES10 GA Anyone else getting a 208 Mb file when downloading the DVD ISO image for SLES-10/z? Anyone has successfully downloaded (4.2 GB) the DVD ISO image for SLES-10/z? Domenico Fofi Sistemi e Tecnologie - Supporto Sistemistico Sogei S.p.A Via Mario Carucci, 99 - 00143 Roma Tel. +39 06 50252685 Cell. +39 335 7264295 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: R: SLES10 GA
Yes. I got the 208 meg file using Internet explorer. Don't use internet explorer. I wound up using Konqueror on an intel linux server, as something in our network was preventing a download larger than 2 gigs to my desktop. You may wish try Firefox 2.0 Beta 1. FOFI DOMENICO <[EMAIL PROTECTED]> Sent by: Linux on 390 Port To LINUX-390@VM.MARIST.EDU cc 07/26/2006 05:21 AM Subject R: SLES10 GA Please respond to Linux on 390 Port Anyone else getting a 208 Mb file when downloading the DVD ISO image for SLES-10/z? Anyone has successfully downloaded (4.2 GB) the DVD ISO image for SLES-10/z? Domenico Fofi Sistemi e Tecnologie - Supporto Sistemistico Sogei S.p.A Via Mario Carucci, 99 - 00143 Roma Tel. +39 06 50252685 Cell. +39 335 7264295 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
Christoph Hellwig wrote: > But that's not how snapshot work. When you do a snapshot the filesystem > is frozen. That means: new file writers are blocked from dirtying the > filesystem throug the pagecache. The filesystem block callers that want > to create new transactions. Then the whole file cache is written out > and the asynchronous write ahead log (journal) is written out on disk. > The filesystem is in a fully consistant state. Trust me, I've > implemented this myself for XFS. Very interresting indeed. This pointed me to reading the lockfs/unlockfs semantics in Linux, and I think I need to withdraw my statement regarding flashcopy snapshots: because of the fact that there is no lockfs/unlockfs interaction when doing flashcopy, and because of dirty pages in the page cache during snapshot, flashcopy will not generate a consistent snapshot. Therefore, using flashcopy on an active volume from outside Linux is _not_ suitable for backup purposes. The only feasible way to get a consistent snapshot is to use dm-snapshot from within Linux. This snapshot copy can later on be used with a backup feature outside Linux. regards, Carsten -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
2006-07-26 Recommended Linux on zSeries code drop to developerWorks
Please refer to: http://www.ibm.com/developerworks/linux/linux390/whatsnew.html for the 2006-07-26 change summary: > New OCOs for Red Hat: - tape_3590 for Red Hat Enterprise Linux 3 Update 8, updated kernel packages (31-bit and 64-bit), kernel 2.4.21-47.EL (2006-07-20) * end of message Mit freundlichem Gruß / Kind regards, Gerhard Hiller eServer Software Management, D4357 IBM Development Lab, Boeblingen/Germany Phone ext. +49-(0)7031 - 16 - 4388 Internet: [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Tue, Jul 25, 2006 at 09:06:54AM +0800, John Summerfied wrote: > To avoid the nitpickers, let's say that David means all filesystems must > be flushed and ro. > > As I understand it, journalling (by default) logs metadata (dirctory > info) but not data. > > If you create a file, that's journalled. If you extend a file, that's > journalled. The data you write to the file are not. > > Let's say that you create a file, write 4K to it, close it. Let's say > you do a backup of the volume externally while the 4K data remains > unwritten. Note: read in "man 2 close" "A successful close does not > guarantee that the data has been successfully saved to disk." > > So now you have journalled (or comitted) metadata that says the file's > got 4K of data in it. > > But, it hasn't. In the ordinary course of events, the data gets written > to disk ans all is well. > > The same sort of thing happens when a file's updated in place, as I > expect databases commonly are. But that's not how snapshot work. When you do a snapshot the filesystem is frozen. That means: new file writers are blocked from dirtying the filesystem throug the pagecache. The filesystem block callers that want to create new transactions. Then the whole file cache is written out and the asynchronous write ahead log (journal) is written out on disk. The filesystem is in a fully consistant state. Trust me, I've implemented this myself for XFS. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
R: SLES10 GA
Anyone else getting a 208 Mb file when downloading the DVD ISO image for SLES-10/z? Anyone has successfully downloaded (4.2 GB) the DVD ISO image for SLES-10/z? Domenico Fofi Sistemi e Tecnologie - Supporto Sistemistico Sogei S.p.A Via Mario Carucci, 99 - 00143 Roma Tel. +39 06 50252685 Cell. +39 335 7264295 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Tue, Jul 25, 2006 at 01:22:53PM +0200, Mark Perry wrote: > I believe that several DB systems offer direct/raw I/O to avoid Linux cache > problems, and that journaling filesystems, although by default only journal > meta-data, offer mount options to journal data too. This of course comes at > a performance price, though Hans Reiser did claim that the new Resier4 FS > will journal data without the previous performance penalties. Journalled filesystems only journal buffered I/O. Direct I/O means you do direct dma operations from the storage controller to the user address space. It's physically impossible to journal. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
