| 1 |
The real solution would have been having a subvolume for the directory. |
| 2 |
Subvolume deletion on BTRFS is near instant. |
| 3 |
Same for ZFS with datasets, etc. |
| 4 |
|
| 5 |
October 22, 2021 9:50 AM, "Rich Freeman" <rich0@g.o> wrote: |
| 6 |
|
| 7 |
> On Fri, Oct 22, 2021 at 8:39 AM Miles Malone |
| 8 |
> <m.malone@××××××××××××××××××.net> wrote: |
| 9 |
> |
| 10 |
>> small files... (Certainly dont quote me here, but wasnt JFS the king |
| 11 |
>> of that back in the day? I cant quite recall) |
| 12 |
> |
| 13 |
> It is lightning fast on lizardfs due to garbage collection, but |
| 14 |
> metadata on lizardfs is expensive, requiring RAM on the master server |
| 15 |
> for every inode. I'd never use it for lots of small files. |
| 16 |
> |
| 17 |
> My lizardfs master is using 609MiB for 1,111,394 files (the bulk of |
| 18 |
> which are in snapshots, which create records for every file inside, so |
| 19 |
> if you snapshot 100k files you end up with 200k files). Figure 1kB |
| 20 |
> per file to be safe. Not a big deal if you're storing large files |
| 21 |
> (which is what I'm mostly doing). Performance isn't eye-popping |
| 22 |
> either - I have no idea how well it would work for something like a |
| 23 |
> build system where IOPS matters. For bulk storage of big stuff though |
| 24 |
> it is spectacular, and scales very well. |
| 25 |
> |
| 26 |
> Cephfs also uses delayed deletion. I have no idea how well it |
| 27 |
> performs, or what the cost of metadata is, though I suspect it is a |
| 28 |
> lot smarter about RAM requirements on the metadata server. Well, |
| 29 |
> maybe, at least in the past it wasn't all that smart about RAM |
| 30 |
> requirements on the object storage daemons. I'd seriously look at it |
| 31 |
> if doing anything new. |
| 32 |
> |
| 33 |
> Distributed filesystems tend to be garbage collected simply due to |
| 34 |
> latency. There are data integrity benefits to synchronous writes, but |
| 35 |
> there is rarely much benefit on blocking on delections, so why do it? |
| 36 |
> These filesystems already need all kinds of synchronization |
| 37 |
> capabilities due to node failures, so syncing deletions is just a |
| 38 |
> logical design. |
| 39 |
> |
| 40 |
> For conventional filesystems a log-based filesystem is naturally |
| 41 |
> garbage-collected, but those can have their own issues. |
| 42 |
> |
| 43 |
> -- |
| 44 |
> Rich |
Archives