Re: mount time for big filesystems

2017-09-01 Thread Dan Merillat
On Fri, Sep 1, 2017 at 11:20 AM, Austin S. Hemmelgarn wrote: > No, that's not what I'm talking about. You always get one bcache device per > backing device, but multiple bcache devices can use the same physical cache > device (that is, backing devices map 1:1 to bcache

Re: mount time for big filesystems

2017-09-01 Thread Austin S. Hemmelgarn
On 2017-09-01 11:00, Juan Orti Alcaine wrote: El 1 sept. 2017 15:59, "Austin S. Hemmelgarn" > escribió: If you are going to use bcache, you don't need separate caches for each device (and in fact, you're probably better off sharing

Re: mount time for big filesystems

2017-09-01 Thread Austin S. Hemmelgarn
On 2017-09-01 09:52, Juan Orti Alcaine wrote: 2017-08-31 13:36 GMT+02:00 Roman Mamedov : If you could implement SSD caching in front of your FS (such as lvmcache or bcache), that would work wonders for performance in general, and especially for mount times. I have seen amazing

Re: mount time for big filesystems

2017-09-01 Thread Juan Orti Alcaine
2017-08-31 13:36 GMT+02:00 Roman Mamedov : > If you could implement SSD caching in front of your FS (such as lvmcache or > bcache), that would work wonders for performance in general, and especially > for mount times. I have seen amazing results with lvmcache (of just 32 GB) for

Re: mount time for big filesystems

2017-08-31 Thread Qu Wenruo
On 2017年08月31日 19:36, Roman Mamedov wrote: On Thu, 31 Aug 2017 12:43:19 +0200 Marco Lorenzo Crociani wrote: Hi, this 37T filesystem took some times to mount. It has 47 subvolumes/snapshots and is mounted with noatime,compress=zlib,space_cache. Is it normal,

Re: mount time for big filesystems

2017-08-31 Thread Roman Mamedov
On Thu, 31 Aug 2017 07:45:55 -0400 "Austin S. Hemmelgarn" wrote: > If you use dm-cache (what LVM uses), you need to be _VERY_ careful and > can't use it safely at all with multi-device volumes because it leaves > the underlying block device exposed. It locks the

Re: mount time for big filesystems

2017-08-31 Thread Austin S. Hemmelgarn
On 2017-08-31 07:36, Roman Mamedov wrote: On Thu, 31 Aug 2017 12:43:19 +0200 Marco Lorenzo Crociani wrote: Hi, this 37T filesystem took some times to mount. It has 47 subvolumes/snapshots and is mounted with noatime,compress=zlib,space_cache. Is it normal, due

Re: mount time for big filesystems

2017-08-31 Thread Roman Mamedov
On Thu, 31 Aug 2017 12:43:19 +0200 Marco Lorenzo Crociani wrote: > Hi, > this 37T filesystem took some times to mount. It has 47 > subvolumes/snapshots and is mounted with > noatime,compress=zlib,space_cache. Is it normal, due to its size? If you could

Re: mount time for big filesystems

2017-08-31 Thread Austin S. Hemmelgarn
On 2017-08-31 07:00, Hans van Kranenburg wrote: On 08/31/2017 12:43 PM, Marco Lorenzo Crociani wrote: Hi, this 37T filesystem took some times to mount. It has 47 subvolumes/snapshots and is mounted with noatime,compress=zlib,space_cache. Is it normal, due to its size? Yes, unfortunately it

Re: mount time for big filesystems

2017-08-31 Thread Hans van Kranenburg
On 08/31/2017 12:43 PM, Marco Lorenzo Crociani wrote: > Hi, > this 37T filesystem took some times to mount. It has 47 > subvolumes/snapshots and is mounted with > noatime,compress=zlib,space_cache. Is it normal, due to its size? Yes, unfortunately it is. It depends on the size of the metadata

mount time for big filesystems

2017-08-31 Thread Marco Lorenzo Crociani
Hi, this 37T filesystem took some times to mount. It has 47 subvolumes/snapshots and is mounted with noatime,compress=zlib,space_cache. Is it normal, due to its size? # time mount /data/R6HW real1m32.383s user0m0.000s sys 0m1.348s # time umount /data/R6HW real0m2.562s user