This post is more than 5 years old
15 Posts
0
3435
Networker issues after mounting an NFS share
Bonjour Tous,
J'utilise en ce moment un script (via la commande save) côté client pour sauvegarder des données sensible, mais voilà que dépuis que le stockage a été changé (avant c'était Netapp rattaché en SAN), avec un montage NFS, j'ai l'erreur ci dessous, avez vous une idée ?
7395:save: Warning: 64-bit inode number uses high order 32-bits.
4181:save: Path /OracleBackup/rman/data_full_08192012 is within 10.241.110.97:/vol/vol_dgbckp
7152:save: 1 remote path(s) specified
Merci de vos retours.
Hi All
I'm actually using a save command to backup my data, But since I change my storage (on Netapp) by mounting an NFS share, i still have this error:
7395:save: Warning: 64-bit inode number uses high order 32-bits.
4181:save: Path /OracleBackup/rman/data_full_08192012 is within 10.241.110.97:/vol/vol_dgbckp
7152:save: 1 remote path(s) specified
Reagrds
vermad1
36 Posts
0
August 20th, 2012 05:00
Hello Rodrigue,
Yes, it is always recommended to use -xL with save for the mount point backups. But the error you are getting (7395:save: Warning: 64-bit inode number uses high order 32-bits.) forced me to think differently.
Deepak
vermad1
36 Posts
0
August 20th, 2012 04:00
Hi,
Looks like you are backing up OCFS.
Please refer to below KB article
http://solutions.emc.com/EMCSolutionView.asp?id=esg106716&usertype=C
Regards,
Deepak
vermad1
36 Posts
0
August 20th, 2012 05:00
One more
http://solutions.emc.com/EMCSolutionView.asp?id=esg99912&usertype=C
rodygogan
15 Posts
0
August 20th, 2012 05:00
Hi Deepak,
Just for information, i also have this output on the client after running the save command:
7153:save: run save on the remote machine(s) or rerun save with "-L"
you don't think is about the share ??
Rodrigue
ble1
14.3K Posts
0
September 2nd, 2012 08:00
The warning was present in earlier versions of NW client on Linux (at least) and has disappeared in more recent verions. In tags you mentioned 7.4 version which would be the version with that warning so if that is correct you may wish to update NW version. I also have one disk device for fun on NA and haven't seen this warning.
ble1
14.3K Posts
0
September 3rd, 2012 02:00
Is that Quantum DX? That's really slow, but the question here is do you read from local volume or network one? Try to make a test where write will go to same device from local disk and from elsewhere over network. That will give you an idea if issue is local or remote (network). Anothe rquestion is, does degradation happens all the time or during certain hours? I know that during recent DX evaluation I've been told mirroring can take quite a lot of power and we were told that instead of one big box much better approach is 2 smaller ones which was a surprise to me.
rodygogan
15 Posts
0
September 3rd, 2012 02:00
Hi All,
Thank you for all your answers, they were helpful, I finally solved the problem by adding the "-L" option to my backup command "save",
but I have another preoccupation: I have a virtual tape library (DX 5000 with SATA disk) attached to my NetWorker server, the problem is that the writing speed on emulated bands are so degraded (5MB/s) and thus leads to long backups periods (100 GB in 07 hours time).
What may be due to the degradation of the writing speed of the DX 5000 ? How can I solve it ?
In addition, I have a Tape Library "Scalr i500" attached to the same networker server , and there, the writing speed is significantly satisfactory.
Best regards
rodygogan
15 Posts
0
September 3rd, 2012 03:00
Hi Hrvoje,
I done the two test ! i'm reading data from a remote client "networker client", and i can confirm that the issue is local.
Yes the degradation happens all the time, exceptionally, we can often see that the backup times were good, but this is very rarely.
Some emulated bands can they impact their writing speeds ?
ble1
14.3K Posts
0
September 3rd, 2012 03:00
Emulated bands should not impact it at all - their "original" speed is the only thing not emulated. Just for the sake of troubleshooting, did you restart server too? Just to rule out any issue with server (which reminds, if you have some sort of AV software - disable it - they don't like backup streams even when they go to tape sometimes).
If after restart you would have same picture, try to write with some OS tool or 3rd party tool to tape to see if you can replicate the issue. Since you say this is local issue, for test use same local data used in previous test. If you still get the same, then ticket with Quantum should be opened and they should run health check on the box.
rodygogan
15 Posts
0
September 4th, 2012 10:00
Hi Hrvvoje / All,
I actually restarted the server, but nothing has changed. I tried "Bigasm" tool to retest the transfer file, and the results are the same.
However, I found that on the DX 5000, one of the disks was constantly in rebuild, and one of the two batteries is disabled.
This Alert can disable library memory cache ? , so that writing operations are done directly on the disk ?
How check the memory cache of librairy ?
Regards
ble1
14.3K Posts
0
September 4th, 2012 12:00
I can't help you with that part as that goes beyond my knowledge. You would need to engage Quantum folks. If write cache is disabled due to rebuild, this will give you slow performance, but rebuild should not take so much time. I believe currently Quantum is shipping 3TB disks, but I assume your model/purchase has 1TB or 2TB disks and it sounds as this is now taking days. Here I assume that disk you see rebuilding is the disk used to store deduplicated data and not the one for landing zone (my understanding is Quantum does "imediate-post" processing using fast cache disks). Batteries, in this case at least, should not have any impact to performance.