On 09/20/2010 09:21 PM, Jeff Layton wrote: >>>> >>>> It's causing some unwanted behaviour. >>>> How can I change that, or is this not changeable? >>>> Stef >>> >>> I think it's just a matter of setting the inode->i_size on the >>> directory. I *think* that when you do a QPathInfo call to a directory >>> via cifs the size comes back 0. Setting this to something else probably >>> means an extra call to the server to get the "real" size (whatever that >>> means). The question is, what should this be set to? >>> >> >> Yes that's a good question. But a share mounted with cifs should >> behave like it is's just a local harddrive partition right? So these >> values are obligatory... >> > > No, not necessarily. > >> In my construction - so I'm speaking only for my own here - >> it's also set the size (and the blocks) in the FUSE fs. Remember, I'm >> using the FUSE fs fuse-workspace >> as the one which is used, and the various mounts to resources like smb >> shares (mounted with cifs of course, managed with autofs) are the >> underlying backend. >> >> My FUSE can correct things, like this. >> >> I wonder, it can correct things, but is it also a must? >> My fuse fs takes these values just from the underlying fs, and this >> can result in >> a size of directories of 4096 when the underlying fs is a mounted >> partition (of for example an USB disk) and zero >> when it's a cifs mounted smb share. Is it a bad thing that these >> values differ in the same fs (in my case thus fuse-workspace)?? >> >> Maybe you know this, else I'll try at the fsdevel list. >> > > It really comes down to this question: > > What is the size on a directory supposed to signify? > (Sorry for digging an old thread..) I think it is really the space required (filesystem thinks it requires) for storing the metadata about the files that would be stored and it depends on the internal datastructures of the filesystem. It never shrinks but expands when the number of files increases. For e.g. On a ext3 filesystem, it looks like the default size of directory on creation is 4096/4k and somewhere between 325 files and 350 files, it changes from 4k to 12k. To get the same behavior on CIFS, the client needs to be aware of the Server filesystem and need to have a rough idea of datastructures unless the Server provides the size. Also, the client needs to increase the size to replicate the same behavior when the number of files on the server increases. I think the nearest information about the Server filesystem the client could get is 'block size' and the client could try to do some clever guess, but it may not always get it correct. -- Suresh Jayaraman -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
