On 07/01/14 06:25, Jim Salter wrote:
> FWIW, Ubuntu (and I presume Debian) will work just fine with a single /
> on btrfs, single or multi disk.
>
> I currently have two machines booting to a btrfs-raid10 / with no
> separate /boot, one booting to a btrfs single disk / with no /boot, and
> one bo
No, the installer is completely unaware. What I was getting at is that
rebalancing (and installing the bootloader) is dead easy, so it doesn't
bug me personally much. It'd be nice to eventually get something in the
installer to make it obvious to the oblivious that it can be done and
how, but
On Jan 6, 2014, at 12:25 PM, Jim Salter wrote:
> FWIW, Ubuntu (and I presume Debian) will work just fine with a single / on
> btrfs, single or multi disk.
>
> I currently have two machines booting to a btrfs-raid10 / with no separate
> /boot, one booting to a btrfs single disk / with no /boot
FWIW, Ubuntu (and I presume Debian) will work just fine with a single /
on btrfs, single or multi disk.
I currently have two machines booting to a btrfs-raid10 / with no
separate /boot, one booting to a btrfs single disk / with no /boot, and
one booting to a btrfs-raid10 / with an ext4-on-mdra
On Jan 6, 2014, at 3:20 AM, Chris Samuel wrote:
> On Sun, 5 Jan 2014 01:25:19 PM Chris Murphy wrote:
>
>> Does the Ubuntu 12.03 LTS installer let you create sysroot on a Btrfs raid1
>> volume?
>
> I doubt it, given the alpha for 14.04 doesn't seem to have the concept yet.
> :-)
>
> https://b
On Sun, 5 Jan 2014 01:25:19 PM Chris Murphy wrote:
> Does the Ubuntu 12.03 LTS installer let you create sysroot on a Btrfs raid1
> volume?
I doubt it, given the alpha for 14.04 doesn't seem to have the concept yet.
:-)
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1266200
All t
On Jan 4, 2014, at 2:16 PM, Jim Salter wrote:
>
> On 01/04/2014 02:18 PM, Chris Murphy wrote:
>> I'm not sure what else you're referring to?(working on boot environment of
>> btrfs)
>
> Just the string of caveats regarding mounting at boot time - needing to
> monkeypatch 00_header to avoid t
Chris Samuel posted on Sun, 05 Jan 2014 20:20:26 +1100 as excerpted:
> On Sat, 4 Jan 2014 02:56:39 PM Chris Mason wrote:
>
>> Seconded +ADs-) We're really focused on nailing down these problems
>> instead of hiding behind the experimental flag. I know we won't be
>> perfect overnight, but it's
Jim Salter posted on Sat, 04 Jan 2014 16:22:53 -0500 as excerpted:
> On 01/04/2014 01:10 AM, Duncan wrote:
>> The example given in the OP was of a 4-device raid10, already the
>> minimum number to work undegraded, with one device dropped out, to
>> below the minimum required number to mount undeg
On Sat, 4 Jan 2014 02:56:39 PM Chris Mason wrote:
> Seconded +ADs-) We're really focused on nailing down these problems instead
> of hiding behind the experimental flag. I know we won't be perfect
> overnight, but it's time to focus on production workloads.
Perhaps an option here is to remove t
On 01/04/2014 01:10 AM, Duncan wrote:
The example given in the OP was of a 4-device raid10, already the
minimum number to work undegraded, with one device dropped out, to
below the minimum required number to mount undegraded, so of /course/
it wouldn't mount without that option.
The issue wa
On 01/04/2014 02:18 PM, Chris Murphy wrote:
I'm not sure what else you're referring to?(working on boot
environment of btrfs)
Just the string of caveats regarding mounting at boot time - needing to
monkeypatch 00_header to avoid the bogus sparse file error (which,
worse, tells you to press a
Chris Mason posted on Sat, 04 Jan 2014 14:51:23 + as excerpted:
> It'll pick the latest generation number and use that one as the one true
> source. For the others you'll get crc errors which make it fall back to
> the latest one. If the two have exactly the same generation number,
> we'll h
On Jan 3, 2014, at 7:59 PM, Jim Salter wrote:
>
> On 01/03/2014 07:27 PM, Chris Murphy wrote:
>> This is the wrong way to solve this. /etc/grub.d/10_linux is subject to
>> being replaced on updates. It is not recommended it be edited, same as for
>> grub.cfg. The correct way is as I already s
On 2014-01-04 15:51, Chris Mason wrote:
> I added mount -o degraded just because I wanted the admin to be notified
> of failures. Right now it's still the most reliable way to notify them,
> but I definitely agree we can do better.
I think that we should align us to what the others raid subsyst
On Sat, 2014-01-04 at 22:28 +1100, Chris Samuel wrote:
> On Sat, 4 Jan 2014 12:57:02 AM Dave wrote:
>
> > I find myself annoyed by the constant disclaimers I
> > read on this list, about the experimental status of Btrfs, but it's
> > apparent that this hasn't sunk in for everyone.
>
> Btrfs will
On Sat, 2014-01-04 at 06:10 +, Duncan wrote:
> Chris Murphy posted on Fri, 03 Jan 2014 16:22:44 -0700 as excerpted:
>
> > I would not make this option persistent by putting it permanently in the
> > grub.cfg; although I don't know the consequence of always mounting with
> > degraded even if no
Chris Samuel posted on Sat, 04 Jan 2014 22:20:20 +1100 as excerpted:
> On Sat, 4 Jan 2014 06:10:14 AM Duncan wrote:
>
>> Btrfs remains under development and there are clear warnings about
>> using it without backups one hasn't tested recovery from or are not
>> otherwise prepared to actually us
On Sat, 4 Jan 2014 12:57:02 AM Dave wrote:
> I find myself annoyed by the constant disclaimers I
> read on this list, about the experimental status of Btrfs, but it's
> apparent that this hasn't sunk in for everyone.
Btrfs will no longer marked as experimental in the kernel as of 3.13.
Unless so
On Sat, 4 Jan 2014 06:10:14 AM Duncan wrote:
> Btrfs remains under development and there are clear warnings
> about using it without backups one hasn't tested recovery from
> or are not otherwise prepared to actually use. It's stated in
> multiple locations on the wiki; it's stated on the kerne
Chris Murphy posted on Fri, 03 Jan 2014 16:22:44 -0700 as excerpted:
> I would not make this option persistent by putting it permanently in the
> grub.cfg; although I don't know the consequence of always mounting with
> degraded even if not necessary it could have some negative effects (?)
Degrad
On Fri, Jan 3, 2014 at 9:59 PM, Jim Salter wrote:
> You're suggesting the wrong alternatives here (mdraid, LVM, etc) - they
> don't provide the features that I need or are accustomed to (true snapshots,
> copy on write, self-correcting redundant arrays, and on down the line). If
> you're going to
On 01/03/2014 07:27 PM, Chris Murphy wrote:
This is the wrong way to solve this. /etc/grub.d/10_linux is subject
to being replaced on updates. It is not recommended it be edited, same
as for grub.cfg. The correct way is as I already stated, which is to
edit the GRUB_CMDLINE_LINUX= line in /etc
On Jan 3, 2014, at 4:42 PM, Jim Salter wrote:
> For anybody else interested, if you want your system to automatically boot a
> degraded btrfs array, here are my crib notes, verified working:
>
> * boot degraded
>
> 1. edit /etc/grub.d/10_linux, add degraded to the
Minor correction: you need to close the double-quotes at the end of the
GRUB_CMDLINE_LINUX line:
GRUB_CMDLINE_LINUX="rootflags=degraded,subvol=${rootsubvol}
${GRUB_CMDLINE_LINUX}"
On 01/03/2014 06:42 PM, Jim Salter wrote:
For anybody else interested, if you want your system to automatica
For anybody else interested, if you want your system to automatically
boot a degraded btrfs array, here are my crib notes, verified working:
* boot degraded
1. edit /etc/grub.d/10_linux, add degraded to the rootflags
GRUB_CMDLINE_LINUX="rootflags=degraded,subvol
On Jan 3, 2014, at 4:25 PM, Jim Salter wrote:
>
> One thing that concerns me is that edits made directly to grub.cfg will get
> wiped out with every kernel upgrade when update-grub is run - any idea where
> I'd put this in /etc/grub.d to have a persistent change?
/etc/default/grub
I don't r
On Jan 3, 2014, at 4:13 PM, Jim Salter wrote:
> Sorry - where do I put this in GRUB? /boot/grub/grub.cfg is still kinda black
> magic to me, and I don't think I'm supposed to be editing it directly at all
> anymore anyway, if I remember correctly…
Don't edit the grub.cfg directly. At the grub
Yep - had just figured that out and successfully booted with it, and was
in the process of typing up instructions for the list (and posterity).
One thing that concerns me is that edits made directly to grub.cfg will
get wiped out with every kernel upgrade when update-grub is run - any
idea whe
On Jan 3, 2014, at 3:56 PM, Jim Salter wrote:
> I actually read the wiki pretty obsessively before blasting the list - could
> not successfully find anything answering the question, by scanning the FAQ or
> by Googling.
>
> You're right - mount -t btrfs -o degraded /dev/vdb /test worked fine.
On Fri, Jan 03, 2014 at 06:13:25PM -0500, Jim Salter wrote:
> Sorry - where do I put this in GRUB? /boot/grub/grub.cfg is still
> kinda black magic to me, and I don't think I'm supposed to be
> editing it directly at all anymore anyway, if I remember
> correctly...
You don't need to edit grub.c
Sorry - where do I put this in GRUB? /boot/grub/grub.cfg is still kinda
black magic to me, and I don't think I'm supposed to be editing it
directly at all anymore anyway, if I remember correctly...
HOWEVER - this won't allow a root filesystem to mount. How do you deal
with this if you'd set up a
Am 03.01.2014 23:56, schrieb Jim Salter:
> I actually read the wiki pretty obsessively before blasting the list -
> could not successfully find anything answering the question, by scanning
> the FAQ or by Googling.
>
> You're right - mount -t btrfs -o degraded /dev/vdb /test worked fine.
don't for
On Fri, Jan 03, 2014 at 05:56:42PM -0500, Jim Salter wrote:
> I actually read the wiki pretty obsessively before blasting the list
> - could not successfully find anything answering the question, by
> scanning the FAQ or by Googling.
>
> You're right - mount -t btrfs -o degraded /dev/vdb /test wor
I actually read the wiki pretty obsessively before blasting the list -
could not successfully find anything answering the question, by scanning
the FAQ or by Googling.
You're right - mount -t btrfs -o degraded /dev/vdb /test worked fine.
HOWEVER - this won't allow a root filesystem to mount. H
Am 03.01.2014 23:28, schrieb Jim Salter:
> I'm using Ubuntu 12.04.3 with an up-to-date 3.11 kernel, and the
> btrfs-progs from Debian Sid (since the ones from Ubuntu are ancient).
>
> I discovered to my horror during testing today that neither raid1 nor
> raid10 arrays are fault tolerant of losing
> mount -t btrfs /dev/vdb /test
> mount: wrong fs type, bad option, bad superblock on /dev/vdb,
>missing codepage or helper program, or other error
>In some cases useful info is found in syslog - try
>dmesg | tail or so
IIRC you need mount option degraded here.
--
To unsubs
37 matches
Mail list logo
