On 10/22/2021 06:15:58 PM, Vitor Hugo Nunes dos Santos wrote:
The real solution would have been having a subvolume for the
directory.
Subvolume deletion on BTRFS is near instant.
Same for ZFS with datasets, etc.
Thanks!
Is it possible to have a hard link from one subvolume to a different
one?
October 22, 2021 9:50 AM, "Rich Freeman" <ri...@gentoo.org> wrote:
> On Fri, Oct 22, 2021 at 8:39 AM Miles Malone
> <m.mal...@homicidalteddybear.net> wrote:
>
>> small files... (Certainly dont quote me here, but wasnt JFS the
king
>> of that back in the day? I cant quite recall)
>
> It is lightning fast on lizardfs due to garbage collection, but
> metadata on lizardfs is expensive, requiring RAM on the master
server
> for every inode. I'd never use it for lots of small files.
>
> My lizardfs master is using 609MiB for 1,111,394 files (the bulk of
> which are in snapshots, which create records for every file inside,
so
> if you snapshot 100k files you end up with 200k files). Figure 1kB
> per file to be safe. Not a big deal if you're storing large files
> (which is what I'm mostly doing). Performance isn't eye-popping
> either - I have no idea how well it would work for something like a
> build system where IOPS matters. For bulk storage of big stuff
though
> it is spectacular, and scales very well.
>
> Cephfs also uses delayed deletion. I have no idea how well it
> performs, or what the cost of metadata is, though I suspect it is a
> lot smarter about RAM requirements on the metadata server. Well,
> maybe, at least in the past it wasn't all that smart about RAM
> requirements on the object storage daemons. I'd seriously look at it
> if doing anything new.
>
> Distributed filesystems tend to be garbage collected simply due to
> latency. There are data integrity benefits to synchronous writes,
but
> there is rarely much benefit on blocking on delections, so why do
it?
> These filesystems already need all kinds of synchronization
> capabilities due to node failures, so syncing deletions is just a
> logical design.
>
> For conventional filesystems a log-based filesystem is naturally
> garbage-collected, but those can have their own issues.
>
> --
> Rich
