Am Donnerstag, 21. Juni 2012 schrieb Goffredo Baroncelli:
Now we have the possibility to move the kernel near the modules, and
this could lead some interesting possibility: think about different
linux installations, with an own kernel version and an own modules
version; what are the
On 06/20/2012 10:47 PM, Goffredo Baroncelli wrote:
This leads to have a separately /boot filesystem. In this case I agree
with you: make sense that the kernel is near the bootloader files.
But if /boot has to be in a separate filesystem, which is the point to
support btrfs at all ? Does
On 06/21/2012 01:46 PM, Martin Steigerwald wrote:
Am Donnerstag, 21. Juni 2012 schrieb Goffredo Baroncelli:
Now we have the possibility to move the kernel near the modules, and
this could lead some interesting possibility: think about different
linux installations, with an own kernel version
On 06/21/2012 03:38 PM, H. Peter Anvin wrote:
But if /boot has to be in a separate filesystem, which is the point to
support btrfs at all ? Does make sense to support only a subset of btrfs
features ?
Yes, and that's another good reason for /boot: btrfs supports that kind
of policy (e.g.
On 06/21/2012 10:05 AM, Goffredo Baroncelli wrote:
On 06/21/2012 03:38 PM, H. Peter Anvin wrote:
But if /boot has to be in a separate filesystem, which is the point to
support btrfs at all ? Does make sense to support only a subset of btrfs
features ?
Yes, and that's another good reason for
On Wed, Jun 20, 2012 at 10:22 AM, H. Peter Anvin h...@zytor.com wrote:
a. Make a snapshot of the current root;
b. Mount said snapshot;
c. Install the new distro on the snapshot;
d. Change the bootloader configuration *inside* the snapshot to point
to the snapshot as the root;
e. Install
On Tue, Jun 19, 2012 at 04:35:59PM -0700, H. Peter Anvin wrote:
On 06/19/2012 07:22 AM, Calvin Walton wrote:
All subvolumes are accessible from the volume mounted when you use -o
subvolid=0. (Note that 0 is not the real ID of the root volume, it's
just a shortcut for mounting it.)
HI all,
Messaggio originale
Da: chris.ma...@fusionio.com
Data: 20/06/2012 1.49
A: H. Peter Anvinh...@zytor.com
Cc: linux-btrfs@vger.kernel.orglinux-btrfs@vger.kernel.org
Ogg: Re: Subvolumes and /proc/self/mountinfo
b. Are there better ways (walking the tree using BTRFS_IOC_TREE_SEARCH
HI all,
Messaggio originale
Da: h...@zytor.com
Data: 20/06/2012 5.22
A: cwillucwi...@cwillu.com
Cc: hel...@hullen.de, linux-btrfs@vger.kernel.org
Ogg: Re: Subvolumes and /proc/self/mountinfo
The concept of what is the root and what is the path is
straightforward for lesser filesystems
Hi All,
Messaggio originale
Da: l...@fajar.net
Data: 20/06/2012 8.31
A: H. Peter Anvinh...@zytor.com
Cc: linux-btrfs@vger.kernel.org
Ogg: Re: Subvolumes and /proc/self/mountinfo
On Wed, Jun 20, 2012 at 10:22 AM, H. Peter Anvin h...@zytor.com wrote:
a. Make a snapshot of the current root
On Tue, Jun 19, 2012 at 06:03:49PM -0600, H. Peter Anvin wrote:
On 06/19/2012 04:49 PM, Chris Mason wrote:
On Mon, Jun 18, 2012 at 06:39:31PM -0600, H. Peter Anvin wrote:
I'm trying to figure out an algorithm from taking an arbitrary mounted
btrfs directory and break it down into:
On 06/20/2012 06:34 AM, Chris Mason wrote:
I want an algorithm, it doesn't have an API per se. I would really like
to avoid relying on blkid and udev for this, though... that is pretty
much a nonstarter.
If the answer is to walk the tree then I'm fine with that.
Ok, fair enough.
On 06/20/2012 05:37 PM, H. Peter Anvin wrote:
On 06/20/2012 05:02 AM, Goffredo Baroncelli kreij...@libero.it wrote:
If I swap (via a rename) __active and __rollback, in the next boot my system
uses a good copy of the root filesystem. This is a simple way to swap
two subvolumes, without
On 06/20/2012 09:34 AM, Goffredo Baroncelli wrote:
At the first I tough that having the /boot separate could be a good
thing. Unfortunately /boot contains both the bootloader code and the
kernel image. The kernel image should be in sync with the contents of
/lib/modules/
This is the
HI,
On 06/20/2012 07:41 PM, H. Peter Anvin wrote:
On 06/20/2012 09:34 AM, Goffredo Baroncelli wrote:
At the first I tough that having the /boot separate could be a good
thing. Unfortunately /boot contains both the bootloader code and the
kernel image. The kernel image should be in sync with
Hallo, Goffredo,
Du meintest am 20.06.12:
[...]
Am not saying that we *should* move the kernel away from /boot. I am
only saying that having the kernel near /lib/modules *has* some
advantages.
Few year ago there are some gains to have a separate /boot (ah, the
time when the bios were
On 06/20/2012 09:15 PM, Helmut Hullen wrote:
Hallo, Goffredo,
Hi Helmut,
Du meintest am 20.06.12:
[...]
Am not saying that we *should* move the kernel away from /boot. I am
only saying that having the kernel near /lib/modules *has* some
advantages.
Few year ago there are some gains
On 06/20/2012 11:06 AM, Goffredo Baroncelli wrote:
Am not saying that we *should* move the kernel away from /boot. I am
only saying that having the kernel near /lib/modules *has* some advantages.
Few year ago there are some gains to have a separate /boot (ah, the time
when the bios were
On 06/19/2012 11:31 PM, Fajar A. Nugraha wrote:
IMHO a more elegant solution would be similar to what
(open)solaris/indiana does: make the boot parts (bootloader,
configuration) as a separate area, separate from root snapshots. In
solaris case IIRC this is will br /rpool/grub.
It is both
On 06/20/2012 11:49 PM, H. Peter Anvin wrote:
On 06/20/2012 11:06 AM, Goffredo Baroncelli wrote:
Am not saying that we *should* move the kernel away from /boot. I am
only saying that having the kernel near /lib/modules *has* some advantages.
Few year ago there are some gains to have a
On Mon, 2012-06-18 at 17:39 -0700, H. Peter Anvin wrote:
I'm trying to figure out an algorithm from taking an arbitrary mounted
btrfs directory and break it down into:
device(s), subvolume, subpath
where, keep in mind, subpath may not actually be part of the mount.
/proc/self/mountinfo
On 06/19/2012 07:22 AM, Calvin Walton wrote:
All subvolumes are accessible from the volume mounted when you use -o
subvolid=0. (Note that 0 is not the real ID of the root volume, it's
just a shortcut for mounting it.)
Could you clarify this bit? Specifically, what is the real ID of the
On Mon, Jun 18, 2012 at 06:39:31PM -0600, H. Peter Anvin wrote:
I'm trying to figure out an algorithm from taking an arbitrary mounted
btrfs directory and break it down into:
device(s), subvolume, subpath
where, keep in mind, subpath may not actually be part of the mount.
Do you want an
On 06/19/2012 04:49 PM, Chris Mason wrote:
On Mon, Jun 18, 2012 at 06:39:31PM -0600, H. Peter Anvin wrote:
I'm trying to figure out an algorithm from taking an arbitrary mounted
btrfs directory and break it down into:
device(s), subvolume, subpath
where, keep in mind, subpath may not
Hallo, Chris,
Du meintest am 19.06.12:
I'm trying to figure out an algorithm from taking an arbitrary
mounted btrfs directory and break it down into:
device(s), subvolume, subpath
where, keep in mind, subpath may not actually be part of the
mount.
Do you want an API for this, or is it
The big reason it isn't here yet is because Kay had this neat patch
to blkid and udev to just put all the info you need into /dev/btrfs
(or some other suitable location). It would allow you to see which
devices belong to which filesystems etc.
btrfs should work even without any udev
On Wed, Jun 20, 2012 at 6:35 AM, H. Peter Anvin h...@zytor.com wrote:
On 06/19/2012 07:22 AM, Calvin Walton wrote:
All subvolumes are accessible from the volume mounted when you use -o
subvolid=0. (Note that 0 is not the real ID of the root volume, it's
just a shortcut for mounting it.)
On 06/19/2012 06:16 PM, cwillu wrote:
The big reason it isn't here yet is because Kay had this neat patch
to blkid and udev to just put all the info you need into /dev/btrfs
(or some other suitable location). It would allow you to see which
devices belong to which filesystems etc.
btrfs
I'm trying to figure out an algorithm from taking an arbitrary mounted
btrfs directory and break it down into:
device(s), subvolume, subpath
where, keep in mind, subpath may not actually be part of the mount.
/proc/self/mountinfo seems to have some of that information, however, it
does not
29 matches
Mail list logo
