All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Slow mounting raid1
Date: Tue, 1 Aug 2017 01:12:19 +0000 (UTC)	[thread overview]
Message-ID: <pan$1eb89$fa81c30b$fe750acd$9555f678@cox.net> (raw)
In-Reply-To: 20170731183047.x2p4vyqd2pvf7t4g@tiamat

Leonidas Spyropoulos posted on Mon, 31 Jul 2017 19:30:47 +0100 as
excerpted:

> Hello,
> 
> I got a raid1 setup of btrfs on a HDD array of 2 disks. The fstab has
> the following mount settings:
>   # cat /etc/fstab | grep raid1
>   UUID=c9db91e6-0ba8-4ae6-b471-8fd4ff7ee72d /media/raid1 btrfs
>   rw,relatime,compress=lzo,space_cache 0 0

If you're doing any snapshotting, you almost certainly want noatime, not 
the default relatime.  Even without snapshotting and regardless of the 
filesystem, tho on btrfs it's a bigger factor due to COW, noatime is a 
recommended performance optimization.

The biggest caveat with that is if you're running something that actually 
depends on atime.  Few if any modern applications depend on atime, with 
mutt in some configurations being an older application that still does.  
But AFAIK it only does in some configurations...

Tho I haven't the foggiest whether it'd affect your mount times...

(FWIW I have a number of pair-device btrfs raid1s, but I'm all-ssd these 
days and mounts seem to be fast enough here.)

> When I try to mount the array it's consistent about 5 seconds+
>   # time umount /media/raid1
>   
>   real    0m0.358s user    0m0.010s sys     0m0.010s # time mount
>   /media/raid1
>   
>   real    0m5.605s user    0m0.504s sys     0m0.071s
> 
> I have this setup for sometime now and from the time I made it the mount
> time went up (I notice that on boot). When I first build that was almost
> instant. In terms of maintenance I regularly run a scrub and rebalance
> every now and then.
> 
> Running kernel 4.11.12 (with -ck patchs)
> 
> Is there something I can do to speed it up (apart buying 2 SSDs :D ). I
> feel like I'm missing something as the usage of the raid is not really
> frequent - just backup mainly.

Is there anything suspect in dmesg during the mount?  What does smartctl 
say about the health of the devices?  (smartctl -AH at least, the selftest 
data is unlikely to be useful unless you actually run the selftests.)

To my awareness there's a few things that can affect mount speed, tho as 
I said I'm on ssd so I really don't know if 5 seconds for spinning rust 
is unusual or not, you'll need the experience of others on that.

1) Attempting to mount filesystems with many devices is of course 
slower.  But two devices shouldn't be a problem.

2) Sometimes a device might take awhile to "spin up" and initialize 
itself.  Since you're still on spinning rust, are the devices perhaps 
spinning down to save power, and the delay you see is them spinning back 
up?

SSDs may have a similar, tho generally shorter and for different reasons, 
delay.  SSDs often have a capacitor that charges up so they can finish a 
write and avoid corrupting themselves in the event of an unexpected power 
loss in the middle of a write.  A lower end device might allow the device 
to appear ready while the capacitor is still charging to avoid long power-
on response times, while higher end devices both tend to have higher 
capacity capacitors, and don't signify ready until they are sufficiently 
charged to avoid issues in "blink" situations where the power supply 
comes back on but isn't immediately steady and might go out again right 
away.

If a device takes too long and times out you'll see resets and the like 
in dmesg, but that normally starts at ~30 seconds, not the 5 seconds you 
mention.  Still, doesn't hurt to check.

3) If the space cache is damaged the mount may take longer, but btrfs 
will complain so you'll see it in dmesg.


[OT but quoting the signature]

> A: Because it messes up the order in which people normally read text.
> Q: Why is it such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

My sentiments exactly! (Well, except that HTML's even more annoying!) =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2017-08-01  1:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-31 18:30 Slow mounting raid1 Leonidas Spyropoulos
2017-08-01  1:12 ` Duncan [this message]
2017-08-01  6:43   ` Leonidas Spyropoulos
2017-08-01 12:32     ` E V
2017-08-01 20:21       ` Leonidas Spyropoulos
2017-08-01 20:40         ` Timofey Titovets

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$1eb89$fa81c30b$fe750acd$9555f678@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.