Is there a way to serialize snapmirrors, i.e., wait until snapmirror #1 finishes before starting snapmirror #2, wait until snapmirror #2 finishes before starting snapmiror #3, etc.?

I'm finding very uneven periods of activity on an R150 despite my best efforts to schedule them with the crontab-like snapmirror.conf. I'd like to have a reasonably busy backup box complete its backups in the shortest amount of time, not extending the backup windows because the R150 is overloaded sometimes or completely idle other times.

Until next time...

The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---

Hi all,

there is a path length limitation of 256 characters for cifs. ok, I know to bypass it with multiple shares or the subst- command.

Question: Is there a theoretical or/and a practical limitation of the path length on the part of NetApp WAFL?

I can not find anything about the path length in NOW, just some hints to be careful with a "very,very" deep path. I also know, that I can increase the maxdirsize to 64MB Default is 10MB ca. 300.000 files.

I am talking about a F810 with 6.2.1. I could imagine there is a limitation by the RAM.

As far as WAFL is concerned, I believe that there is a 256 character limit on a file name, which is not a full path. In other words, a WAFL directory entry does not allow a file name over 256 characters.

There is no limit on directory nesting depth in WAFL. For those who understand Unix, you could run the following to make a very deep directory tree:

while :; do # infinite loop mkdir mydir cd mydir done

This would result in

mydir/mydir/mydir/mydir/ ... (until you run out of inodes or hit your quota)

This is a perfectly legal directory tree for WAFL, but cumbersome and not very useful.

Most Unix systems have a pathname limit of 1024 characters. But this does not prevent you from creating a directory tree that is too deep to be accessed with absolute pathnames. You can still access deeply nested files by drilling down with "cd" and using relative pathnames.

Perhaps the 256 character limit you refer to for CIFS is just the file name limit, rather than the pathname limit. Or perhaps it is the pathname limit for a share, which is the top level directory of a share. Beneath a share, directories can be nested as deeply as you want. As with Unix (NFS), I am sure that CIFS can handle deeply nested directories -- you just need to drill down into them.

Some file backup and archiving programs have problems with deeply nested directories because they store the full pathname of each file. Deeply nested trees result in pathnames that may be too long for the backup software to handle. I am pretty sure that the native netapp dump utility can handle any WAFL volume, no matter how deep the directories are.

The maxdirsize has nothing to do with directory nesting depth. It has more to do with "directory width", i.e., how much space may a directory use to store its directory entries. A directory entry is variable length because it contains a file name, which can be from 1 to 256 characters.

Steve Losen scl@virginia.edu phone: 434-924-0640

University of Virginia ITC Unix Support