Hi,
On 06/13/2014 01:32 AM, chru...@suse.cz wrote:
> Hi!
>> +/*
>> + * lib/tst_fs_link_count.c
>> + * Try to get maximum number of subdirectories under directory @dir in a
>> + * mounted file system.
>> + * In its implementation, it uses mkdir(2) to create numbers of
>> subdirectories
>> + * in @dir, try to reach the limit and will try at most 65535 times. If
>> EMLINK
>> + * is hit, we can think the maximum number has been reached, return this
>> number.
>> + * Meanwhile under directory @dir: there will be numbers of subdirectories,
>> + * Like below:
>> + * testdir1, testdir2, testdir3, ..., testdir${returned number}.
>> + * If some errors(ENOSPC, EDQUOT) occur or no errors at all, we can think
>> that
>> + * the maximum number of subdirectories is infinite or not reachable because
>> + * of filesystem's free space, for this case, return 0.
>> + * If some other errors occur, we call tst_brkm(TBROK, ...).
>> + */
>> +int tst_fs_fill_subdirs(void (*cleanup) (void), const char *dir);
> This function actually tries to figure out maximal number of elements a
> directory can hold (it does not matter if these are files or
> directories). So it should be renamed to tst_fs_fill_dir().
Indeed there is difference between creating files and directories. When
creating a regular file under a
directory, the directory's inode count won't be increased, but if creating a
sub-directory in a directory,
the parent directory's inode count will be increased(add 1). This is because
the ".." in the created
sub-directory will point to the parent directory's inode. For regular files,
there is no need to increase
parent's inode count.
This url has an explanation: http://www.vidarholen.net/contents/blog/?p=18
Steps to verify this:
# mkfs.ext3 -N 80000 /dev/loop0
# mount -t ext3 /dev/loop0 mntpoint/; cd mntpoint
# mkdir lege; cd lege
# for ((i=1; i<= 40000; i++)); do touch $i; done; # this will succeed and you
will create 40000 regular files.
# for ((i=1; i<= 40000; i++)); do mkdir $i; done;
this will fail. in ext3, you are only allowed to create 31998
sub-directories(there is already "." and "..")
This limit is imposed by " #define EXT3_LINK_MAX 32000" defined in ext3 kernel
source code.
For ext2, the limit is also 32000. for ext4, this is 65000 or infinite, which
depends whether dir_index
feature is enabled.
>
> Moreover I've been unable to get EMLINK for any filesystem in this case,
> it looks like ENOSPC is what you get when maximal number of elemenents
> in directory is reached (the free space on filesystem is fine but you
> are out of inodes/clusters etc).
I can get EMLINK when running in an ext2 or ext3 file system under RHEL5.10GA:-)
Could you please test the above steps? It should work.
And if kernel config option "CONFIG_EXT4_USE_FOR_EXT23" value is "y", you
actually
have tests with ext4. Now you have to execute "mkfs.ext4 -O ^dir_index device"
first.
>
> I have, slightly modified version of this patch I will commit once this
> function is figured out but before I do so I wanted to ask if you plan
> to use this function for any testcase? If not I would remove it because
Yeah, this function will be used.
For rename(2) or renameat(2)'s EMLINK test, the manpage sasys that:
EMLINK The file named by old is a directory, and the link count of the
parent directory of new would exceed {LINK_MAX}.
We need to use tst_fs_fill_subdirs() to construct the condition.
Regards,
Xiaoguang Wang
> as it is it's not implemented correctly and fixing it would require more
> research and effort.
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
