[llvm] r329648 - [CachePruning] Fix comment about ext4 per-directory file limit. NFC
Fangrui Song via llvm-commits
llvm-commits at lists.llvm.org
Tue Apr 10 15:23:15 PDT 2018
On 2018-04-10, Peter Collingbourne wrote:
>As I said that wasn't the limit I was hitting. Here is the program that I
>wrote:
>
>#include <stdint.h>
>#include <errno.h>
>#include <stdio.h>
>#include <sys/types.h>
>#include <sys/stat.h>
>#include <fcntl.h>
>#include <unistd.h>
>#include <string.h>
>
>int main() {
> for (uint64_t i = 0;; ++i) {
> char buf[256];
> snprintf(buf, 256, "d/%032lx", i);
> if (i % 65536 == 0)
> puts(buf);
> int fd = open(buf, O_CREAT);
> if (fd == -1) {
> printf("open: %s\n", strerror(errno));
> return 1;
> }
> close(fd);
> }
>}
>
>The output ends in:
>
>d/00000000000000000000000000980000
>d/00000000000000000000000000990000
>d/000000000000000000000000009a0000
>d/000000000000000000000000009b0000
>d/000000000000000000000000009c0000
>d/000000000000000000000000009d0000
>d/000000000000000000000000009e0000
>d/000000000000000000000000009f0000
>open: No space left on device
>
>df:
>Filesystem 1K-blocks Used
>Available Use% Mounted on
>[redacted] 856678580 780069796 33068920 96% [redacted]
>
>df -i:
>Filesystem Inodes IUsed
>IFree IUse% Mounted on
>[redacted] 54411264 18824333 35586931 35% [redacted]
>
>Peter
I suspect your case triggered a hashed btree split that would consume
more disk space. Can you try again on a newly created ext4 filesystem
(ensuring it has sufficient space left).
Your example works well on my machine: I cannot created files in
other directories as well. dumpe2fs tells me the inodes are used up.
>
>On Tue, Apr 10, 2018 at 1:40 PM, Fangrui Song <maskray at google.com> wrote:
>
> su
> truncate -s 100G 100G
> mkfs.ext4 100G
> mkdir ext4
> mount 100G ext4
> cd ext4
>
> mkdir p
> cd p
> python3 -c 'for i in range(6600000):\n with open(str(i),"w"): pass'
>
> It runs out of inodes with some message like:
>
> OSError: [Errno 28] No space left on device: '6553587'
>
> umount ext4; dumpe2fs 100G # says the inodes are used up
> ...
> Free inodes: 0
> ...
>
> On 2018-04-10, Peter Collingbourne wrote:
>
> No, these were empty files. It wasn't an inode limit because I could
> still
> create files in other directories.
>
> Peter
>
> On Tue, Apr 10, 2018 at 10:35 AM, Fangrui Song <maskray at google.com>
> wrote:
>
> On 2018-04-09, Peter Collingbourne wrote:
>
> Are you sure about that? I'm pretty sure that before writing
> that
> comment I
> wrote a small program that created lots of files (not
> subdirectories)
> in a
> directory until it started getting error messages, which started
> happening at
> around 6000000 files.
>
> Peter
>
> I guess you created a file of 100GiB. The number of inodes is
> roughly
> 6553600.
>
> 100*1024*1024*1024 / 16384 = 6553600.0 where 16384 is the default
> bytes-per-inode (man mke2fs).
>
> % truncate -s 100G 100G
> % mkfs.ext4 100G
> % dumpe2fs 100G
> .....
> Inode count: 6553600
> .....
>
> Each file consumes one inode and the number of files in that
> directory
> is limited by this factor.
>
> On Mon, Apr 9, 2018 at 5:12 PM, Fangrui Song via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
> Author: maskray
> Date: Mon Apr 9 17:12:28 2018
> New Revision: 329648
>
> URL: http://llvm.org/viewvc/llvm-project?rev=329648&view=rev
> Log:
> [CachePruning] Fix comment about ext4 per-directory file
> limit. NFC
>
> There is a limit on number of subdirectories if dir_nlinks is
> not
> enabled (31998), but per-directory number of files is not
> limited.
>
> Modified:
> llvm/trunk/include/llvm/Support/CachePruning.h
>
> Modified: llvm/trunk/include/llvm/Support/CachePruning.h
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/
> llvm/
> Support/
> CachePruning.h?rev=329648&r1=329647&r2=329648&view=diff
> =============================================================
> =======
> =======
> ===
> --- llvm/trunk/include/llvm/Support/CachePruning.h (original)
> +++ llvm/trunk/include/llvm/Support/CachePruning.h Mon Apr 9
> 17:12:28 2018
> @@ -52,9 +52,8 @@ struct CachePruningPolicy {
> /// the number of files based pruning.
> ///
> /// This defaults to 1000000 because with that many files
> there
> are
> - /// diminishing returns on the effectiveness of the cache,
> and
> some file
> - /// systems have a limit on how many files can be
> contained in a
> directory
> - /// (notably ext4, which is limited to around 6000000
> files).
> + /// diminishing returns on the effectiveness of the cache,
> and
> file
> + /// systems have a limit on total number of files.
> uint64_t MaxSizeFiles = 1000000;
> };
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
> --
> --
> Peter
>
> --
> 宋方睿
>
> --
> --
> Peter
>
> --
> 宋方睿
>
>--
>--
>Peter
--
宋方睿
More information about the llvm-commits
mailing list