ITEM: BF7155L

sysback of compress filesystems is taking 2x the amount of time

Question:

Env:
  AIX 4.1.4
  Disk 9gb
  sysback 3.3.2.4
  Scsi Adapter F/W

Desc:
  The customer states with two filesystem each 8gb in size
  one is compressed and the other is not compressed.  The
  customer is backing up about 2gb of data in each filesystem
  (same file).  The customer is using the mkjfsback command
  (inode backup).  In the filesystem without compression it
  it backed up 2.7gb per hour on the filesystem with 
  compression it backed up .97gb per hour.  Over twice as
  slow.

Action:
  I had the customer use the backbyinode command which 
  showed the same problem as the mkjfsback command.
  Sysback will run the backbyinode command.  I had the
  customer run the backbyname command which seemed to work
  without problems.  So the problem appears to be with the
  backbyinode command.

WORK DONE BY LEVEL THREE  (L3PERF)
-----------------------------------
The issue here might be just with why is the difference between
backup by name and backup by inode so large on a compressed
filesystem; the difference is hardly noticeable on a non-compressed
filesystem.
I talked to James about this today, and he will try to get me
some data using the same files in a 2GB filesystem that is
compressed.
 I did some tests using two filesystems that are both exactly the same
size and less than 2GB. Both filesystems also had exactly the same
files in them. One filesystem was compressed, and the other was not.
.A backbyname of the filesystems took about the same time on each
filesystem.
A backbyinode, however, too 2x as long on the compressed filesystem
as it tid on the non-compressed.
More investigation underway ...

When backbyinode runs on the compressed filesystem, the
"user" time in vmstat goes up and there are fewer system
calls.  When backbyname runs on the compressed filesystem,
the user time goes down, but the system calls go up.
Tprof shows that most of the user time is in "shared library"
for the backbyinode case. However, it lists the
/sbin/comp.uext file as the shared library. This is actually
a kernel extension which is part of the compression kproc
jfsc.  Most of this user time is spent in encode_decode() which
is in comp.uext.
.It looks like backbyinode is decompressing the file whereas
with backbyname, decompression doesn't seem to be happening.

backbyinode links libfs noshared and calls the decompress
routine to decompress the files from user space.
backbyname lets the kernel do all the decompression. The
difference could be going back and forth from user space
to kernel space. However, I think backbyinode is also
decompressing small pieces at a time.
VMM readahead doesn't seem to make an impact on backbyname (
I tried turning it off to see if that was what was helping
backbyname, but it didn't make much of a difference).
.In the meanwhile, I informed James of what was going on.
He wasn't going to use compressed filesystems anymore,
but I told him that backbyname works just fine. So he
will do a test using "backup of directories" option in
sysback rather than doing a "backup of filesystems".



Support Line: sysback of compress filesystems is taking 2x the amount of time ITEM: BF7155L

Dated: February 1996 Category: N/A

This HTML file was generated 99/06/24~13:30:22

Comments or suggestions?
Contact us