After booting on rescuecd and adding the mount options below the
system can be booted, but it still performing terribly… the main
observation is this

# time rm -f qradar-leef-17.log
real        0m13.648s
user       0m0.000s
sys          0m0.105s

This is a 2Mbyte file and it takes 13 secs to rm…. what can be the
reason behind it and how to fix such weird behavior? Is this a file
system corruption? Some misconfiguration? Or should I start planning
to use some more traditional filesystem for this use-case?

Thank you for your help

Pál, László

> On 2021. Feb 15., at 20:30, Pal, Laszlo <> wrote:
> So,
> I'm trying to recover this stuff... this is a CentOS7 based system
> running for almost two years. It was never too fast, but did what I
> intended to do, but today I've observed very very bad performance on
> ls, rm and other complicated commands. Like rm <any single file> takes
> forever and in iotop I can see this command is using 50% of i/o
> together with btrfs-transacti, so something definitely wrong
> I've added ram and cpu to the VM, but it does not help. Now, I'm also
> trying to modify fstab to add noatime, autodefrag
> In the journal I can see some "free cache file invalid, skip" warnings
> Can anyone offer me some help, so at least I can boot the machine
> (right now the boot times out on mount task, so I can have either
> emergency mode or rescuecd)
> Thank you
> Laszlo
> On Mon, Feb 15, 2021 at 3:53 PM Pal, Laszlo <> wrote:
> Hi,
> I'm not sure this is the right place to ask, but let me try :) I have
> a server where I mainly using btrfs because of the builtin compress
> feature. This is a central log server, storing logs from tens of
> thousands devices, using a text files in thousands of directories in
> millions of files.
> I've started to think it was not the best idea to choose btrfs for this :)
> The performance of this server was always worst than others where I
> don't use btrfs, but I thought this is just because the i/o overhead
> of compression and the not-so-good esx host providing the disk to this
> machine. But now, even rm a single file takes ages, so there is
> something definitely wrong. So, I'm looking for some recommendations
> for such an environment where the data-security functions of btrfs is
> not as important than the performance.
> I was searching the net for some comprehensive performance documents
> for months, but I cannot find it so far.
> Thank you in advance
> Laszlo

Reply via email to