On 2022-01-26 20:13, dmitri maziuk wrote:
On 2022-01-26 12:57 PM, Josip Deanovic wrote:
The number of files per directory is far bigger and is unlikely to
get reached, especially not for this use case.
The limit is one thing, the scaling is another. I agree: 40TB of 10GB
files is not enough to see the slow-down on any modern system, you'd
need an order of magnitude more files to get there. Still it's
something to be aware of when deciding on volume size.
40 TB is 40960 GB which would give 4096 files, 10 GB in size.
Order of magnitude would be 40960 files which is still nothing.
Right now on my laptop I have 291794 files and 34481 directories
and that's only under /usr.
I had systems with hundreds of millions of files on UFS2 (FreeBSD)
and systems with billions of files on ext3 (Linux) and that was like
15 years ago.
As far as I can remember there were no issues with read/write
performance related to the number of files. The issue was backup
which would take a lot of time to traverse the whole file system.
This is a problem common to all hierarchical databases without
some kind of indexing employed to deal with the issue.
As long the full path of a file is known, I don't think the
read/write performance of a file would change noticeably with
the increase of number of files on the file system.
Modern file systems are using directory indexing so even
searching through a file system doesn't take too long but
it's common sense that the time needed to perform a lookup
would increase (not necessary linearly) with the number of
files on the file system.
In any case, Bacula knows the path names of the file volumes
and doesn't need to search the file system. I can't imagine
the setup where the number of files on the local file system
containing Bacula file volumes would pose a problem.
Regards!
--
Josip Deanovic
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
