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...]
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.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?
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).
smime.p7s
Description: S/MIME Cryptographic Signature
