Backup of CIFS share: every empty directory eats 131072 bytes!

[Mihails Nikitins]

Hi,

This might be posted in Omniback forum, but I think it's more general problem.

I mount CIFS share on HP-UX host ( CIFS/9000 Client B8724AA A.01.06) and try running incremental backup by Omniback II v.4.0. From listing of session files I see that all empty directories (without changes since the previous backup) require 131072 bytes on tape!

Here is session statistics.

Directories ........ 3808
Regular files ...... 18
Symbolic links ..... 0
SYSV FIFOs ......... 0
BSD sockets ........ 0
Block Devices ...... 0
Character Devices .. 0
Unknown Objects .... 0
----------------------------
Objects Total ...... 3826
Kbytes Total ...... 488686


So I need 131072 x 3808 = 499122176 bytes to store nothing. It's really stupid for copying 18 changed files!

I suspect the problem is related to a filesystem parameter like 'bytes per inode' (131072 is maximum value for JFS). I see in other session listings that empty directories occupy 1024 bytes for HP-UX and 8192 bytes for Tru64.

Please don't advise avoid copying CIFS shares. :-) The topic as well as my environment was already discussed.
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xf687402f24d5d61190050090279cd0f9,00.html

Many thanks and points for your ideas!

BR,
Mihail

[Eric Raeburn]

[reply]

[Eric Raeburn · Accepted solution]

[Sorry about previous empty reply; the system failed to attach my attachment.]

Mihails,

I work in the CIFS/9000 Lab at HP. This message addresses your recent posts about the
CIFS Client, concerning performance and "big empty directories".

First the performance issue.

Check the following in cifsclient.cfg:

1. Log Levels

The lines you show from your log file indicate that log level [2] ("debug") is turned
on (info = logLevel 0, error = logLevel 1, ...). Logging is expensive and any log level
that reports typical activity slows performance, so only those levels that report unusual
activity (errors and warnings) should be on, in particular only "info", "error",
"netbiosError" and "warn" should be on for normal operations, all the other log levels
should be commented out (see cifsclient.cfg.default).

2. nfsAttributeCaching

This parameter is a trade-off between performance and security. By setting it to "yes"
you should see a performance improvement, but you should first understand the tiny
security hole this opens. If user A accesss a file to which only he has access rights,
and user B attempts to access the file immediately after A, then it is possible that B
could "inherit" A's permissions from the attribute cache. If nfsAttributeCaching is set
to "no", file attributes are always requested from the server, so the entire chain of
events that triggers a network request-reply starts up. The security hole is plugged,
but performance is affected. Chances are that your backup program is hitting this
situation for every file it examines. Turning on attribute caching for the duration of
the backup should help. It makes a huge difference for similare activities we have tested,
such as tar(1) with large numbers of files. If you are the only user of the Unix host
on which the CIFS Client is running, the security hole should never be an issue.

"Big empty directories"

First, examine the size of the backup itself. Chances are, the size that Omniback reports
is incorrect, due to a dilemma in Unix-Windows interoperability. This is the problem:
CIFS servers emulate Microsoft filesystems. Certain file attributes on Unix do not exist
in DOS or NT based filesystems like Windows, such as group ownership, the execute bit, and
directory size. Thus the CIFS Client uses some arbitrary value for such attributes. In
the case of directory size, it is hard-coded to the value you reference (128 x 1024),
regardless of the contents of the directory. The value is meaningless; it represents a
non-existent attribute on the server's filesystem. Unless Omniback pre-allocates space
based on this value, the backup is probably not as huge as reported, Omniback has only
"believed" the faked value and used it in its calculations.

In a future release, we may make this value configurable, or set it to a "nicer" value,
like 1024. What would be your preference?

Note that on Unix systems running CIFS servers that have implemented CIFS Unix
Extensions, this problem does not exist; the Unix filesystem attributes are accurate. The
extensions are implemented in the CIFS/9000 Client and Server and in the latest Samba code.

-Eric Raeburn

[Mihails Nikitins]

Hi Eric,

I'm always happy to hear from developers in these forums!

I already know about logging level impact on CIFS performance. I thank you for describing nfsAttributeCaching parameter. Now I see that big empty directory seem to be just claimed. I tried to backup CIFS share to disk file, it's really small after compression! Here is my thread about it.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x5ba53a1c04ffd61190050090279cd0f9,00.html

Anyway, a "nicer" value like 1024 would be OK.

I also found that "du -sk" reports wrong sizes for
CIFS shares, see the following link at

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x254d0fe6d0f7d61190050090279cd0f9,00.html

Thanks once more for your input!

BR,
Mihails