I occasionally see the following message from the savegroup completion
notification for one of my groups:
* client:/0/exports/dir1 save: Unable to get size of extended attribute
names : No such file or directory
* client:/0/exports/dir1 save: Warning: Problem getting extended
attribute names
The backup for the save set always completes, however, and I am able to
recover the data. Has anyone else seen
this before??? Is this message significant? Is this anything to worry
about or is this just harmless noise? Or does it
mean that NW was unable to back up one or more files or that it somehow
had a problem in determining which files
to back up, so maybe there's one or more files that should have been
backed up that weren't?
When this message occurs, I never see any errors specifying a specific
file that it was not able to backup, so I'm curious what
exactly NW is trying to do when this happens, and what I should infer
from this. The whole thing is very nebulous.
We're running NW 7.2.2 on Solaris 2.9 (primary server). Data gets
backed up to a storage node (RH ES3) running
NW 7.2.2. Client is running NW 7.2.2 on Linux RH AS3. The parent file
system (/0) for the affected directory is type ext3.
'lsattr -d /0/exports/dir1' shows '-------------'. Ditto for all the
directories and files underneath when running 'lsattr /0/exports/dir1'.
Also, 'getfattr -d /0/exports/dir1' returns nothing. Ditto for 'getfattr
-R /0/exports/dir1'. There are several other save sets that live
under /0/exports that I do not see this message on, however.
I checked the listing, and there was an earlier post back in December
2006 titled: "Unable to get size of extended attribute names"
concerning this issue wherein recovery of the data restored empty files.
But in that case, there was also a "Function not implemented"
message that accompanied this message. There were some suggestions that
something might be up with the file system itself; e.g. 'lsattr'.
According to the original author's final reply, downgrading the client
to 7.1 resolved the issue after it was apparent that 'getfattr -d
/pathname'
resulted in "Function not implemented". I'm not seeing this.
There are 20 save sets in this group. This is the only group that I see
this message on, and it's
only occurring on one of the 20 save sets (always the same one) and all
from the same client.
The save set (path) in question still appears to get backed up. 'Auto
media verify' is set to 'Yes'
for the given pool, and the affected save set always gets listed with a
'V' for verification even
when this message occurs.
It has occurred 8 times since Jan 2007. The group runs nightly. Also,
cloning is enabled
for the group. Queries against the media database for the group do not
indicate any 'clflags' for any of
the save sets, and all the 'ssflags' values are vF or vrF.
Thanks.
George
--
George Sinclair - NOAA/NESDIS/National Oceanographic Data Center
SSMC3 4th Floor Rm 4145 | Voice: (301) 713-3284 x210
1315 East West Highway | Fax: (301) 713-3301
Silver Spring, MD 20910-3282 | Web Site: http://www.nodc.noaa.gov/
- Any opinions expressed in this message are NOT those of the US Govt. -
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
