Hi Chris,
On Friday 20 November 2009, Chris Mason wrote:
> On Fri, Nov 20, 2009 at 07:50:06PM +0100, Goffredo Baroncelli wrote:
> > Hi all,
> >
> > after the Chirs (Ball) email, I thought about a possible btrfs file-system
> > layout, which may permit to snapshot the root and mount (if required)
On Fri, Nov 20, 2009 at 1:50 PM, Chris Mason wrote:
> COW semantics require touching btree nodes all the way up to the root of
> the btree, but this is different from the directory. Directories are
> stored in the btree, but you won't have to touch more than 8 or so btree
> levels regardless of h
On Fri, Nov 20, 2009 at 07:50:06PM +0100, Goffredo Baroncelli wrote:
> Hi all,
>
> after the Chirs (Ball) email, I thought about a possible btrfs file-system
> layout, which may permit to snapshot the root and mount (if required) an old
> snapshot of the root.
[ very clear description of a file
On Fri, Nov 20, 2009 at 01:24:42PM -0600, David Nicol wrote:
> On Fri, Nov 20, 2009 at 12:50 PM, Goffredo Baroncelli
> wrote:
>
> > Any comments ?
> > BR
> > G.Baroncelli
>
>
> since COW semantics require touching directory entries all the way up
> to the root of the subvolume, for transaction-
On Fri, Nov 20, 2009 at 12:50 PM, Goffredo Baroncelli
wrote:
> Any comments ?
> BR
> G.Baroncelli
since COW semantics require touching directory entries all the way up
to the root of the subvolume, for transaction-intensive applications
it would make sense to provide something that works like "
Hi!
> The problem is btrfs randomly changes the "current master"
> superblock of the filesystem. Only 1 of the devices will
> be mountable. You just have to try the other ones, like:
>
> > $ mount -t btrfs /dev/loop0 /mnt/btrfs
> > mount: wrong fs type, bad option, bad superblock on /dev/loop
Hi all,
after the Chirs (Ball) email, I thought about a possible btrfs file-system
layout, which may permit to snapshot the root and mount (if required) an old
snapshot of the root.
A btrfs file-system has the capability to be partitioned in subvolumes. Every
subvolume has a name. The root of
Hi Chris, reproduced the hang; attached are the logs from the sysrq's you
suggested.
sysrq.txt.gz
Description: GNU Zip compressed data
On Nov 20, 2009, at 10:35 AM, Chris Mason wrote:
> On Thu, Nov 19, 2009 at 06:18:49PM -0500, John Dong wrote:
>> Managed to get some kernel logs this time. S
On Thu, Nov 19, 2009 at 06:18:49PM -0500, John Dong wrote:
> Managed to get some kernel logs this time. Some sort of deadlock?
Ok, if you can still access the machine could you please run sysrq-w and
sysrq-t. That will print out the stacks of the stuck procs. We've
probably got a lock inversion
On Fri, Nov 20, 2009 at 8:31 AM, Albert Strasheim wrote:
> We are experimenting with btrfs and we've run into some problems.
> We are running on two Sun Storage J4400 Arrays containing a total of
> 48 1 TB disks.
> With 24 disks in the btrfs:
> Now with one more disk:
False alarm. Turns out the s
10 matches
Mail list logo
