I have a program which reads all the files in a path given as argument into a buffer (And does something with it). The program makes use of several file processing APIs such as: stat(), fopen(), read() etc..
Now, it is possible that the directory specified by the path is actually a volume which is nfs mounted from a filer. Now, as far as I can tell it does not make any difference to the program whether the path contains files that are local to the client or if it is nfs mounted from the filer.
What I want to know is whether the program will work if CIFS (or SMBFS) was used to mount the volume. (or any other protocol other than NFS)
(I thought cifs was only for windows, but turns out you can use cifs to mount a volume on a linux machine, I tried using cifs to mount the volume but my kernel does not support it.
% r mount -t cifs sys1:/vol/vol1 ~/dir1
mount: fs type cifs not supported by kernel)
For plain file reading that should be okay. Of course, not necessarily apply if you use chmod or other filesystem-specific features.
Try smbmount if your kernel doesn't have cifs compiled in (or in some distros without mount.cifs), or if possible just recompile the kernel with the needed option.
So, I was able to do a cifs mount ! One thing that is odd is that whenever I mount a volume using cifs.. the size of the destination directory (mount point) becomes zero
% mkdir temp
% ls -ld temp/
drwxr-xr-x 2 vj enr 4096 Jun 21 14:41 temp/
% r mount -t cifs sys1:/vol1 ~/temp
% ls -ld temp/
drwxrwxrwx 3 root root 0 Jun 21 12:14 temp/
% cd temp/
% ls -l
total 10264
-rwxrwSrwt 1 root root 10506529 Jun 21 12:15 file10MB*
Is this the expected behaviour ? If not, then what does it depend on ?
It's not the size of the directory. It's the size of the inode entry representing that directory on the filesystem. How large that value is depends on how many "links" point to it, which is more likely dependent on the number of entries in the directory, rather than the individual file sizes. So, a directory with just a big ISO file of several Gigabytes, it is not unusual that the directory inode size is a mere under 100 bytes, while your /etc inode size may be many times larger.
To tell the size of files under a directory, use du.
As for a remotely mounted directory, I think you cannot rely on that size reported anyway. Because that is ordinarily the inode size occupied by that directory entry in the filesystem, and for a remotely mounted volume that inode size is mostly irrelevant anyway (not a local filesystem).
Oh I get it, its just the size of the inode entry for that directory. Even then, why is it 0 ? Is it because we just cannot say anything about the inode entry for that directory in the remote file system ?
Well, I did an nfs mount and the size of directory inode did /not/ change. ls -l still reports it as 4096.
hmmm.. is 4096 the size of inode entry of the directory on the local machine or is it the size of the inode entry of the volume on the remote filesystem.
I will be inclined to say, for remote filesystems, that size is many times irrelevant or otherwise meaningless, and quite probably it can just be anything. That value I guess is filesystem/driver-specific. Say, SSHFS may take an entirely different approach from CIFS. As CIFS is designed for Windows-based systems, its protocol may not necessarily honour the "inode size" at all even though you may be mounting a Unix remote partition. As you can see, there are a lot of possible reasons.
If you are really so keen in knowing why that is 0 or 4096 or something else, you should look at the driver source code. It's the only way to know why it is so.