Re: Very various speed of grep operation on btrfs partition

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]

On 2015-12-03 14:36, Михаил Гаврилов wrote:
> Today on work I needed searching some strings in repository. Only
> machine with windows was available. I am was using grep from Cygwin
> for this task and I am was surprised about speed of NTFS partition.I
> decided to repeat this task on my home Linux workstation.
>
[...snip...]
>  From results we see that search goes sometimes instantly less than a
> second, and sometimes lasts 4 minutes. /home partition formatted in
> BTRFS filesystem. I would be interested investigate what is related to
> search speed. And make that search was always goes less than a second.
>
> Here is my mount options:
> UUID=82df2d84-bf54-46cb-84ba-c88e93677948 /home btrfs
> subvolid=5,autodefrag,noatime,space_cache,inode_cache,nodatacow 0 0
>
> # uname -a
> Linux localhost.localdomain 4.2.6-301.fc23.x86_64+debug #1 SMP Fri Nov
> 20 22:07:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> How to start investigation?
>
Well, what other things are accessing the filesystem at the same time? 
If you've got something like KDE running with the 'semantic desktop' 
stuff turned on, than that will seriously impact the performance of 
other things using that filesystem.

The other thing to keep in mind, is that caching may be impacting things 
somewhat.  To really get a good idea of performance for something like 
this, you should run 'sync' followed by 'echo 3 > 
/proc/sys/vm/drop_caches' (you'll need to be root for the second one) 
prior to each run, and ideally have nothing else running on that filesystem.

On a separate note, if you're either running on a 64-bit system, or have 
less than about 2^31 files on the FS, inode_cache will slow things down. 
  It's intended for stuff like mail spools where you have billions of 
files being created and deleted over a few weeks, and quickly use up the 
inode numbers.  On almost all systems, it will make things run slower, 
and possibly result in non-=deterministic filesystem performance like 
what you are seeing here.

Additionally, do you have some particular reason that you absolutely 
_need_ nodatacow to be enabled for the FS?  It usually has no impact on 
performance, but it removes any kind of error correction for file data 
(checksums can't be used safely without COW semantics).  It probably has 
no direct impact on what you're seeing here, but it is something that 
really shouldn't be used in most cases at the filesystem level (it can 
be done on given subvolumes or directories, and that's the recommended 
way to do it if you don't want to go down to the per-file level).


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]