[plug] Filesystems for lots of inodes

[Chris Hoy Poy]

In regards to the truncating files - just check your kernel versions before
switching to new kernels. It's pretty solid and safe as long as you don't
go chucking the latest kernels onto the Nas device.

There aren't any better options imho. SSDs are not immune to the issue
either. Sometimes they suck more because they have lame internals that
prefetch blocks etc

/Chris.

On Sat, 4 Jan 2020, 7:24 pm Chris Hoy Poy, <chris at hoypoy.id.au> wrote:

> Hi all,
>
> XFS has an online "defragment" which works by copying entire files to
> "free contiguous space" - so as long as you have free contiguous space, it
> will keep up. You can tell it to run for like an hour or two a night (watch
> it doesn't clash with your backups). There are various bugs around where
> files will get truncated.
>
> Zfs is okay but tbh it will suffer from the same issues going forward
> (fragmentation!).
>
> Btrfs - wouldn't bother
>
> I think ext4 has an online defragment too, but I haven't played with it in
> production.
>
> In general, XFS is my go-to, and we do use it a lot. I have used XFS for
> this purpose for over a decade in various implementations :-)
>
> Most file systems suck horribly if they have less then 20% capacity
> (obviously) but over time, when used as a backup and trimmed, you can't
> avoid having to copy files to defrag them.
>
> Cheers
> /Chris
>
> On Sat, 4 Jan 2020, 5:10 pm Brad Campbell, <brad at fnarfbargle.com> wrote:
>
>> Woooo. It finished
>>
>> srv:/mnt# time du -hcs *
>> 2.3M    30seafield_home
>> ..... <snip> .....
>> 3.3T    total
>>
>> real    945m18.422s
>> user    2m35.516s
>> sys     14m13.933s
>>
>> Only 15 hours. Now lets see how long a dump/restore takes.
>>
>> To put it in perspective. Raw sequential on this array is ~500MB/s. It
>> took a couple of hours to clone the entire filesystem using dd.
>>
>> --
>> An expert is a person who has found out by his own painful
>> experience all the mistakes that one can make in a very
>> narrow field. - Niels Bohr
>> _______________________________________________
>> PLUG discussion list: plug at plug.org.au
>> http://lists.plug.org.au/mailman/listinfo/plug
>> Committee e-mail: committee at plug.org.au
>> PLUG Membership: http://www.plug.org.au/membership
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20200104/8966a957/attachment.html>