sysback of compress filesystems is taking 2x the amount of time
Scsi Adapter F/W
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
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
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
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
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
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?