ADSM-L

Re: updated thoughts: AIX and async I/O

2003-04-30 11:43:49
Subject: Re: updated thoughts: AIX and async I/O
From: "PINNI, BALANAND (SBCSI)" <bp3965 AT SBC DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 30 Apr 2003 10:43:42 -0500
Thanks Andy Thanks for the info.

-----Original Message-----
From: Wilcox, Andy [mailto:andy.wilcox AT AQUILA-NETWORKS.CO DOT UK]
Sent: Wednesday, April 30, 2003 10:35 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: updated thoughts: AIX and async I/O

I have had a play with testing the advantages of direct I/O and asynch I/O
on a testing server... (F50 with two internal SSA RAID sets for disk pool
and DB... The Disk pool was made up of two 20GB volumes on a large file
enabled FS. The DB was made up ). Basically If you disable direct I/O the
most noticable difference is that there is a lot more CPU utilisation
(average of 30-40% higher) when writing to the disk stoage pools. In real
terms of throughput, with one or two clients there isn't anything worth
noting whether enabled or disabled, but when you have more clients, the
direct I/O option being enabled helps to provide a higher throughput across
all the clients.

Now the async I/O option I haven't manage to prove either way as I cannot
chuck enough workload at it to make it worthwhile. I am however apprehensive
about enableing on the live servers without knowing exactly where the line
is drawn between direct I/O and async I/O. Some areas of documentation
indicate the the async I/O is relevant to DB and LOG volumes and Direct I/O
is relevant to disk volumes, where as other documentation indicates that
both Direct I/O and async I/O are relevant to the db/log vols and disk
pools. The first thought is what you would hope where as the second could
have some very interesting results, which is why I am holdingt fire at the
moment. Has anyone any thoughts here about which way to go and whether or
not the async I/O options is only relevant to DB/log volumes etc???

Cheers

Andy Wilcox
Midrange Services
Aquila Networks Services



> -----Original Message-----
> From: Paul Ripke [SMTP:stixpjr AT BIGPOND.NET DOT AU]
> Sent: 25 April 2003 08:52
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: AIX and async I/O
>
> On Friday, Apr 25, 2003, at 09:46 Australia/Sydney, David Bronder wrote:
>
> > Wilcox, Andy wrote:
> >>
> >> Good observation there Paul, I just haven't noticed... but as you
> >> quite
> >> rightly say, direct I/O is enabled by default... I am still curious
> >> about
> >> the AIXASYNCIO option and whether or not that can provide any
> >> advantages or
> >> disadvantages... Hopefully I will have some findings in the very near
> >> future
> >> and I will let you know.
> >
> > Based on information in the Redbook "IBM Tivoli Storage Manager Version
> > 5.1 Technical Guide Redbook" (SG24-6554-00) and feedback from a PMR
> > that
> > I opened, there are a couple of limitations of note with AIXASYNCIO and
> > AIXDIRECTIO options.
> >
> > Direct I/O only works for storage pool volumes.  Further, it "works
> > best"
> > with storage pool files created on a JFS filesystem that is _not_ large
> > file enabled.  Apparently, AIX usually implicitly disables direct I/O
> > on
> > I/O transactions on large file enabled JFS due to TSM's I/O patterns.
> > To ensure use of direct I/O, you have to use non-large file enabled
> > JFS,
> > which limits your volumes to 2 GB each.
>
> That's a real shame, IMHO. I notice that open(2) doesn't mention any
> special handling of O_DIRECT between open and open64. I'd say most
> TSMers
> would have their stgpool volumes bigger than 2 GB.
>
> > Asynchronous I/O supposedly has no JFS or file size limitations, but is
> > only used for TSM database volumes.  Recovery log and storage pool
> > volumes do not use async I/O.  AIX 5.1 documentation mentions changes
> > to
> > the async I/O interfaces to support offsets greater than 2 GB, however,
> > which implies that at least some versions (32-bit TSM server?) do in
> > fact have a 2 GB file size limitation for async I/O.  I was unable to
> > get clarity on this point in the PMR I opened.
>
> Well, looks like AIX has had large file AIO support since large file
> support was added (4.2.1, from memory). I see the matching routine
> definitions aio_write and aio_write64 on a 4.3.3 system. It should just
> depend if TSM was compiled with _LARGE_FILES defined or not.
>
> I'd run a trace on dsmserv, but ours are on Solaris...
>
> Cheers,
> --
> Paul Ripke
> Unix/OpenVMS/TSM/DBA
> 101 reasons why you can't find your Sysadmin:
> 68: It's 9AM. He/She is not working that late.
> -- Koos van den Hout
>
>
> **************************************************************************
> **************************
> Confidentiality: This e-mail and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity
> to whom they are addressed.  If you have received this e-mail in error,
> use of this information (including disclosure, copying or distribution)
> may be unlawful.  Please notify postmaster AT aquila-networks.co DOT uk. and
> delete the message immediately.
>
> Security: Internet e-mail is not a 100% secure communications medium.
>
> Viruses: This e-mail (and any attachments) has been checked (using Sophos
> Sweep 3.63 + patches) and found to be clean from any virus infection
> before leaving.
> Therefore neither Aquila Networks Services Ltd nor Midlands Electricity
> plc  or any of their group undertakings  (as defined by the Companies Act
> 1989) (together referred to as the "Companies") accept legal
> responsibility for this message or liability for the consequences of any
> computer viruses which may have been transmitted by this e-mail.
>
> Monitoring: All electronic communications with the Companies may be
> monitored in accordance with the UK Regulation of Investigatory Powers
> Act, Lawful Business Practice Regulations, 2000.  If you do not consent to
> such monitoring, you should contact the sender of this e-mail.
>
> Aquila Networks Services Limited,
> Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB
> Registered in England and Wales number 3600545
> This e-mail may be sent on behalf of any of the Companies.
> **************************************************************************
> **************************

<Prev in Thread] Current Thread [Next in Thread>