On Fri, 21 Jul 2000, Marcus Watts wrote:
> Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
> > Date: Fri, 21 Jul 2000 14:14:26 -0400
> > From: Jeffrey Hutzelman <[EMAIL PROTECTED]>
> > To: Jeff Blaine <[EMAIL PROTECTED]>, Lyle Seaman <[EMAIL PROTECTED]>
> > cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > Subject: Re: 103 character full pathname fails?
> >
> > [I'm mailing relevant people directly in addition to copying the list,
> > since otherwise it will be September before anyone sees my comments. Grrr.]
> >
> >
> > On 07/21/00 13:34:12 -0400 Jeff Blaine <[EMAIL PROTECTED]> wrote:
> >
> > > 'touch 84794578943985349' returns the following with truss (Solaris):
> > >
> > > stat64("84794578943985349", 0xFFBEF830) Err#2 ENOENT
> > > creat64("84794578943985349", 0666) Err#27 EFBIG
> > > touchwrite(2, " t o u c h", 5) = 5
> > > : write(2, " : ", 2) = 2
> > > 84794578943985349write(2, " 8 4 7 9 4 5 7 8 9 4 3 9".., 17) = 17
> > > cannot create
> > > write(2, " c a n n o t c r e a".., 15) = 15
> > > llseek(0, 0, SEEK_CUR) = 8208
> > > _exit(1)
> > >
> > > EFBIG is 'File too large' in /usr/include/sys/errno.h
> > >
> > > Same error code with strace under Red Hat 6.2
> >
> > In many cases, the error codes you get from operations on AFS files must be
> > interpreted based on the fileserver platform. What platform is the
> > fileserver in question, and what is errno 27 on that platform?
> >
> >
> > -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
> > Sr. Research Systems Programmer
> > School of Computer Science - Research Computing Facility
> > Carnegie Mellon University - Pittsburgh, PA
> >
> >
> >
>
> The problem is not with large filenames. I can do this:
> touch
>84794578943985349847945789439853498479457894398534984794578943985349847945789439853498479457894398534984794578943985349
> with no problems. (That's a 119 character filename.) 'Course, I may not have
> the same version of solaris as you, and I almost certainly used a different version
> of AFS.
>
> Since you've only included output from "truss", it's difficult to say if
> this is a problem with the cache manager or file server. You might find
> it worthwhile to find a version of "tcpdump" that decodes fileserver RX
> packets and use that, or failing that, decode the packets by hand.
>
> Before doing this, you should try varying the circumstances of the error
> to determine when it does and does not happen. It may be dependent
> on the fileserver version#, the client version#, or could very likely
> be due to some problem with a particular directory or volume, and not
> true at large. Random stupid questions: just how many files do you already
> have in that directory? Also, what is the output from "csh -c limit",
> specially RLIMIT_FSIZE? Are you using an NFS/AFS translator?
>
> The cache manager appears to be willing to return EFBIG if:
> ...
> (anything that makes a directory entry) if the directory is "full".
> (Sorry, I don't know how many blobs can fit in a directory.)
Hm. Yeah, that's probably what's happening. A directory entry can hold
up to 16 characters of filename; remaining characters are held in
extension entries, which hold up to 32 characters each. All of these
entries for a given filename must be contiguous and in the same page.
A page holds 64 entries (EPP), and modern fileservers allow up to 1023
pages in a directory (BIGMAXPAGES); these constants are declared in
dir/dir.h.
The directory module returns EFBIG if it cannot find a page in which
enough contiguous blobs are free. This should be an unusual situation,
but it sounds like that's what's happening.
-- Jeff
