I am experiencing a problem with dump since upgrading the filers to 5.2.2. I contacted Netapp for help as you can see below. Netapp is still working on this problem and said no one has reported anything like this and this is first of its kind. Netapp cannot duplicate the problem because they don't have autoloader inhouse. I was hoping perhap you can contact some of your customers who has a simular setup as I do here. I have a DLT4700 connected to a filer. I dump the filer to tapes and use restore to restore or list the content of the tapes. Since the upgrade I notice on the dump log the inode from a next tape is not steadily increase but start from 0. I didn't expect the dump could be bad because what have written to tape's number increment steadily. I would greatly appreciated if you can look into this. Thank you in advance for any help you can.
--Ling.
Steven B. Roche Senior Account Executive Open Systems Solutions ph 508-359-4248 ext. 319 fx 508-359-5215 em sroche@opensystems.com
I am experiencing a problem with dump since upgrading the filers to 5.2.2. I contacted Netapp for help as you can see below. Netapp is still working on this problem and said no one has reported anything like this and this is first of its kind. Netapp cannot duplicate the problem because they don't have autoloader inhouse. I was hoping perhap you can contact some of your customers who has a simular setup as I do here. I have a DLT4700 connected to a filer. I dump the filer to tapes and use restore to restore or list the content of the tapes. Since the upgrade I notice on the dump log the inode from a next tape is not steadily increase but start from 0. I didn't expect the dump could be bad because what have written to tape's number increment steadily. I would greatly appreciated if you can look into this. Thank you in advance for any help you can.
How many tapes do you expect the backup set to use? If it's more than one have you checked that the drive is actually ejecting and loading a new tape? After the second tape? What I'm asking is, 'Is the next backup overwriting the first?'. Are you backing up multiple sets in sequence? What filesystem does restore tv say is on the tape?
Do the file names match what you expect to see and only the inode numbers are strange?
----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw@cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU
I am experiencing a problem with dump since upgrading the filers to 5.2.2. I contacted Netapp for help as you can see below. Netapp is still working on this problem and said no one has reported anything like this and this is first of its kind. Netapp cannot duplicate the problem because they don't have autoloader inhouse. I was hoping perhap you can contact some of your customers who has a simular setup as I do here. I have a DLT4700 connected to a filer. I dump the filer to tapes and use restore to restore or list the content of the tapes. Since the upgrade I notice on the dump log the inode from a next tape is not steadily increase but start from 0. I didn't expect the dump could be bad because what have written to tape's number increment steadily. I would greatly appreciated if you can look into this. Thank you in advance for any help you can.
Hi. You are encountering bug 11068. This bug is described online at NOW. In general, the bug does not have an impact on the restore-ability of the dump tapes.
You might try running a restore to make sure that your tapes are viable. (Note, in 5.3 there is a new restore -N option, that allows you to verify that the dump was successful, without actually restoring any data!) If they are, don't worry. If you see problems, read below.
If you are concerned, you can use the 'B' option on your dumps. This will prevent the bug from occurring.
If the 'B' option is not a viable solution (some people don't like it because it does cost you some tape space), there are patches available on top of 5.2.2 that have fixes for the bug. If you call customer support and ask them for a 5.2.2 variant that fixes bug 11068, they can fix you up.
Finally, the bug is officially fixed in 5.3.
Hopefully this information helps.
Stephen "Livin' La Vida Loca" Manley File System Recovery Pop Sensation
-
scw＠seas.ucla.edu -
sroche -
stephen＠netapp.com