linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: CACook@quantum-sci.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Kernel Modules
Date: Sat, 9 Jul 2011 18:39:11 +0100	[thread overview]
Message-ID: <20110709173910.GH4325@carfax.org.uk> (raw)
In-Reply-To: <201107091028.04403.CACook@quantum-sci.com>

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

On Sat, Jul 09, 2011 at 10:28:03AM -0700, CACook@quantum-sci.com wrote:
> On Saturday 9 July, 2011 10:12:43 you wrote:
> > If your btrfs lives on two or more devices you will have to run 'btrfs
> > device scan' prior to mount or give all devices as arguments to mount.btrfs.
> 
> Ohhh, I'd added a disk drive without modifying fstab.  Thanks.
> 
> Where would you put a device scan to happen at boot?

   This is distribution dependent, but I do know that Debian will put
it in your initrd for you if you install Debian's btrfs-tools package.
If you have your root FS on btrfs, you *must* put the scan in an
initrd (or specify all the root devices as mount options in your
kernel command-line).

   If you don't use an initrd, then add the scan to your startup
scripts anywhere before the point that filesystems are mounted, and
anywhere after the point that block devices are detected (typically
when udev is started).

> On another subject, I guess there are two ways to remove old snapshot directories:
> - btrfs subvolume delete
> - rm -rf
> 
> I understand that snapshots are cumulative for files and do not duplicate, but is it necessary to use the subvolume delete command to preserve the integrity of remaining snapshots?

   No, effectively each snapshot is independent of the others (by the
magic of copy-on-write). When items from a snapshot are deleted, the
filesystem automatically cleans up by updating the extent reference
counts.

> And also, about once a week KDE locks up on me after a suspend, and
> I have to power-cycle it.  Is there any maintenance I should do on a
> btrfs part when this happens?

   No, if the storage stack from filesystem all the way down to the
drive platter handles barriers correctly, then btrfs should always be
in a consistent state, even over a power-cycle.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
              --- Welcome to Rivendell,  Mr Anderson... ---              

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

  reply	other threads:[~2011-07-09 17:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-09 16:19 Kernel Modules CACook
2011-07-09 17:12 ` Andreas Philipp
2011-07-09 17:28   ` CACook
2011-07-09 17:39     ` Hugo Mills [this message]
2011-07-10  8:24     ` Goffredo Baroncelli
2011-07-09 17:33 ` Helmut Hullen
2011-07-10  6:56   ` Felix Blanke
2011-07-10  7:29     ` Helmut Hullen
2011-07-10 14:24       ` Felix Blanke
2011-07-10 15:57         ` Helmut Hullen
2011-07-10 16:42           ` Felix Blanke

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=20110709173910.GH4325@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=CACook@quantum-sci.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).