Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: C Anthony Risinger <anthony@extof.me>
To: Calvin Walton <calvin.walton@gmail.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC-PATCH] Re: mounting arbitrary directories
Date: Sun, 28 Nov 2010 04:07:18 -0600	[thread overview]
Message-ID: <-3532760747667207688@unknownmsgid> (raw)
In-Reply-To: <1290918133.14274.20.camel@nayuki>

On Nov 27, 2010, at 10:22 PM, Calvin Walton <calvin.walton@gmail.com>
wrote:

> On Sat, 2010-11-27 at 21:19 -0600, C Anthony Risinger wrote:
>> i have read just recently and in the past that btrfs supports COW for
>> _any_ file/directory (this is reflinks, yes?), and today i
>> accidentally noticed that i can mount a directory as well (if it's in
>> the top level volume at least).
>>
>> eg. if i have a "regular" directory (not a subvolume) in the top-
>> level:
>>
>> /__boot
>>
>> i can mount it with:
>>
>> mount -o subvol=__boot /dev/sda /mnt
>
> The 'subvol' option actually works using the same mechanism as a bind
> mount. The fact that it works using a directory is purely a
> coincidence
> - I would not expect it to be officially supported, and you shouldn't
> rely on it.
>
>> i am working on an update to my initramfs hook that will utilize
>> extlinux, and this property to provide seamless kernel level system
>> rollbacks, and i want to make sure it's safe to do this.
>
> To handle system rollbacks, you really should be using subvolumes and
> snapshots, not regular directories.
>
>> also, is there a way to target an arbitrary directory?  does "subvol"
>> support paths yet, or maybe via "subvolid" somehow?  essentially i
>
> I don't think that it would be very hard to make subvol= support a
> path
> instead of only one level deep. Actually, I think I could make a patch
> for that myself... I've included it here. Mildly tested, but I'm not
> really a kernel programmer and might have missed something -
> particularly with regards to the locking.
>
>> just want to mount a directory inside a snapshot at /boot, so when
>> users upgrade there kernels, the images are visible to extlinux
>> (which
>> cannot yet peek inside or use subvolumes, so it has to be a regular
>> directory in the top-level volume)
>
> Ah, this is the first I've heard that extlinux doesn't support reading
> files in subvolumes. That's an unfortunate limitation :/

Hrrrm... Well I thought I'd be clever and use this little trick one
time to update my kernel... Anyways I oops out like 3 times in a row
(last func was <something>.clone in each IIRC) and now I'm stuck with
only my mobile since my server isn't set up yet and my  SSD just
failed on my netbook yesterday :-(

Sooooo, if anyone can help me recover this partition long enough to
grab a few things... I would be most grateful :-) I think I have
everything critical, but I'd rather take another look :-) Right now I
can't mount; mount is failing w/bad superblock.

/me promises to never recklessly sabotage himself after being warned <
6 hrs earlier

C Anthony [mobile]

  parent reply	other threads:[~2010-11-28 10:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-28  3:19 mounting arbitrary directories C Anthony Risinger
2010-11-28  4:22 ` [RFC-PATCH] " Calvin Walton
2010-11-28  9:41   ` C Anthony Risinger
2010-11-28 10:07   ` C Anthony Risinger [this message]
2010-11-29 17:42     ` C Anthony Risinger
2010-12-03  9:41       ` C Anthony Risinger

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=-3532760747667207688@unknownmsgid \
    --to=anthony@extof.me \
    --cc=calvin.walton@gmail.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