| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
A customer (EPFL) asked me a question regarding the vrestore
performance.
Config:
=======
AS2100 (4 CPUs ev4/275 - 640MB) Unix v3.2d-2
HSZ40c (FW v3.1)
Disks RZ40 (LYG0) 5 disks/RAID5 set
Write back cache policy A
Flush timer dafualt (10sec)
No cache UPS
Host functionnality mode A
chunk size = 256 blocks
TZ877 for vdump/verstore
AdvFS filesystems
It took him ~6 hours to vdump his 24MB filesystems, but the
restore is running ~1GB/hour (restore still running, 20GB
after 20 hours...)
Alan's answer in note #9952 makes me beleive the time here is
correct and has to do with the RAID5 config which needs 4 I/Os
for each write...
>> Typically, RAID-5 writes require reading the old copy of
>> the data and the corresponding XOR. From this, the new
>> XOR is calculated and then the new data and XOR can be
>> written. This is called read-modify-write and requires
>> four I/Os for every write.
But does it fully answer the factor 4 ?
Doesn't a READ operation on a RAID5 set requires multiple I/Os
as well ?
Customer asked me if using NSR would help ?
I personnaly feel that if it has really to do with the way RAID5
operations are performed, using a different way to save/restore
his data will not improve a lot the figures...
Can someone give me his point of view on that matter, I woulnd't
give a wrong answer to my customer !
Cheers,
============================
Alain MARTIN/SSG Switzerland
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 9977.1 | Use the cache. | SSDEVO::ROLLOW | Dr. File System's Home for Wayward Inodes. | Thu May 29 1997 11:07 | 30 |
If the array isn't reduced, reading a RAID-5 should be like reading from a stripe set with as many members as are in the array. It may perform slightly better than the equivalent capacity as a stripe set, since there is one more member to handle the load. Of course, in the case of a backup and restore, most of the I/O is serial and there's probably little benefit from it being an array. When the array is reduced, everything changes. Different write algorithms have to be used and reads have to touch all the members whenever the data is on the missing disk. Your configuration information didn't clearly indicate whether the cache was enabled for the particular unit. If not you should use it. If the customer won't, but has one available, find out why they won't. Another thing that could be slowing down the restore is the fact that it is an Advanced File System. If many small files are being restored, that is going cause a heavy write load to the load. Which by going to RAID-5 will everything down. Since the log will quickly fill in the face of more incoming metadata, cleaning it will cause more writes to the file system, once again slowed down because it is RAID-5. Assuming that AdvFS still only logs metadata changes, a vrestore of many small files is probably the worst possible I/O that you could have to a RAID-5. | |||||
| 9977.2 | KITCHE::schott | Eric R. Schott USG Product Management | Thu May 29 1997 21:52 | 8 | |
run sys_check on the system...it will give you the data you are looking for http://www-unix.zk3.dec.com/tuning/tools/sys_check/sys_check.html you need to check that not only you have a WBC, but that it is enabled for the unit...see the sys_check output...if you still have problems, post a pointer for us to see to the output | |||||
| 9977.3 | Thanks ! Write back was not enabled... | LEMAN::MARTIN_A | Be vigilant... | Fri May 30 1997 05:42 | 15 |
Thanks to both Alan and Eric for your advise.
I checked with the customer and you are right, the write back cache
is not enabled for the units, as they have the RAID license but they
miss the write-back one !
It seems however that the RAID license is enough for using the
write-back functionnality, so we'll take the necessary action so
that they can use write back on these units and will run sys_check
as well to have a better understanding of their config...
Cheers,
============================
Alain MARTIN/SSG Switzerland
| |||||