CIO/DIO and JFS2 read ahead Post: 302258238

8 More Discussions You Might Find Interesting

1. HP-UX

Read-ahead in HP-UX

One cool thing about unix is that it predicts disk blocks that you may need and tries to have them in core before you need them. Over the years, various unix vendors tried various algorithms to improve performance. HP has patented their latest algorithm... Multi-threaded Read Ahead Prediction...

2. AIX

JFS and JFS2

hi all, can sumbody give me a link which gives the basic layout of JFS, JFS2 and the veritas file system. and i also want to know about the data structures used in this filsystem thanx in advance

3. Shell Programming and Scripting

PERL look ahead and behind ...

I would like to search a router config file for "ip address $ip", once found, I want to grab the line just before that contains "interface $interfacetype" basically saying, 10.3.127.9 is assigned to "Loopback1" given the below as an example. interface Loopback1 ip address 10.3.127.9...

4. AIX

Jfs and jfs2

Hi all, Can anyone define the difference between jfs and jfs2 filesystem as well as usage of jfs log files.... Thanks....

5. Red Hat

How to enable AIO and DIO on rhel5 64bit?

Hi Friends, Please help me to understand, how to enable async disk IO and Direct disk IO in ext3 filesystem on rhel5. Regards, Arumon

6. AIX

Slow NFS when cio/dio enabled

Hi, I have a bit of a NFS problem on AiX 6.1 : When I set the mount to cio and dio - needed for a database app - Everything slows down. The following is copying 700mb, top one is a normal mount bottom one is a mount with the cio/dio option enabled : # ./a.sh Wed Jan 11 11:41:24 GMT 2012...

7. AIX

AIX JFS2 content

Hello! I have a LPAR with 51GB RAM topas shows 21% of memory for client pages (~11Gb) svmon -G show 2906772 client pages in use (~11Gb) but then i try to investigate per process client memory usage svmon -P -O filtertype=client and summarize inuse column, i get only 347880 pages...

8. UNIX for Beginners Questions & Answers

Two days ahead

Hi, I have a code that will show one day ahead, how to make it show two days ahead p-dev1-db-tst:/$ day=$(TZ=IST-24 date +%d) p-dev1-db-tst:/$ echo $day 17 p-dev1-db-tst:/$ Regards, Adam

LEARN ABOUT LINUX

git-cherry

GIT-CHERRY(1)							    Git Manual							     GIT-CHERRY(1)

NAME

       git-cherry - Find commits yet to be applied to upstream

SYNOPSIS

       git cherry [-v] [<upstream> [<head> [<limit>]]]

DESCRIPTION

       Determine whether there are commits in <head>..<upstream> that are equivalent to those in the range <limit>..<head>.

       The equivalence test is based on the diff, after removing whitespace and line numbers. git-cherry therefore detects when commits have been
       "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1).

       Outputs the SHA1 of every commit in <limit>..<head>, prefixed with - for commits that have an equivalent in <upstream>, and + for commits
       that do not.

OPTIONS

       -v
	   Show the commit subjects next to the SHA1s.

       <upstream>
	   Upstream branch to search for equivalent commits. Defaults to the upstream branch of HEAD.

       <head>
	   Working branch; defaults to HEAD.

       <limit>
	   Do not report commits up to (and including) limit.

EXAMPLES

   Patch workflows
       git-cherry is frequently used in patch-based workflows (see gitworkflows(7)) to determine if a series of patches has been applied by the
       upstream maintainer. In such a workflow you might create and send a topic branch like this:

	   $ git checkout -b topic origin/master
	   # work and create some commits
	   $ git format-patch origin/master
	   $ git send-email ... 00*

       Later, you can see whether your changes have been applied by saying (still on topic):

	   $ git fetch	# update your notion of origin/master
	   $ git cherry -v

   Concrete example
       In a situation where topic consisted of three commits, and the maintainer applied two of them, the situation might look like:

	   $ git log --graph --oneline --decorate --boundary origin/master...topic
	   * 7654321 (origin/master) upstream tip commit
	   [... snip some other commits ...]
	   * cccc111 cherry-pick of C
	   * aaaa111 cherry-pick of A
	   [... snip a lot more that has happened ...]
	   | * cccc000 (topic) commit C
	   | * bbbb000 commit B
	   | * aaaa000 commit A
	   |/
	   o 1234567 branch point

       In such cases, git-cherry shows a concise summary of what has yet to be applied:

	   $ git cherry origin/master topic
	   - cccc000... commit C
	   + bbbb000... commit B
	   - aaaa000... commit A

       Here, we see that the commits A and C (marked with -) can be dropped from your topic branch when you rebase it on top of origin/master,
       while the commit B (marked with +) still needs to be kept so that it will be sent to be applied to origin/master.

   Using a limit
       The optional <limit> is useful in cases where your topic is based on other work that is not in upstream. Expanding on the previous example,
       this might look like:

	   $ git log --graph --oneline --decorate --boundary origin/master...topic
	   * 7654321 (origin/master) upstream tip commit
	   [... snip some other commits ...]
	   * cccc111 cherry-pick of C
	   * aaaa111 cherry-pick of A
	   [... snip a lot more that has happened ...]
	   | * cccc000 (topic) commit C
	   | * bbbb000 commit B
	   | * aaaa000 commit A
	   | * 0000fff (base) unpublished stuff F
	   [... snip ...]
	   | * 0000aaa unpublished stuff A
	   |/
	   o 1234567 merge-base between upstream and topic

       By specifying base as the limit, you can avoid listing commits between base and topic:

	   $ git cherry origin/master topic base
	   - cccc000... commit C
	   + bbbb000... commit B
	   - aaaa000... commit A

SEE ALSO

       git-patch-id(1)

GIT

       Part of the git(1) suite

Git 1.8.5.3							    01/14/2014							     GIT-CHERRY(1)