Thank you for your report.
I'm going to reprocude this panic and fix it maybe next week.
Regards,
taruisi
(2009/12/12 5:57), Josef Bacik wrote:
> On Wed, Nov 18, 2009 at 02:42:14PM +0900, TARUISI Hiroaki wrote:
>> New feature to list up subvolume/snapshots under
>> specified tree of file is intro
Hi,
I don't know how a hard link becomes to a soft link, hard link
across subvolumes should not allowed in btrfs.
Hard link contains target inode number but not target tree.
So, if we can create such hard link normally, it points to
a file which has same inode number in same subvolume.
As for
Am Mittwoch 18 November 2009 22:28:27 schrieb briaeros007:
> Hello,
> For some days, i've got oops on my system and i've investigate it a bit.
> The trouble was with "posix_acl_equiv_mode" , and for some reason
> (corrupted metadata ?) btrfs sometimes call it with "acl"==NULL
> This function doesn
This introduces a new btrfsctl option, -m, to allow you to set the default'ly
mounted subvolume. You can do
btrfsctl -m /your/subvolume
and that will make that subvolume the subvolume that is mounted by default, or
you can do
btrfsctl -m /any/subvolume
and this will make the subvolume with tr
This patch needs to go along with my previous patch. This lets us set the
default dir item's location to whatever root we want to use as our default
mounting subvol. With this we don't have to use mount -o subvol=
anymore to mount a different subvol, we can just set the new one and it will
just m
On Wed, Nov 18, 2009 at 02:42:14PM +0900, TARUISI Hiroaki wrote:
> New feature to list up subvolume/snapshots under
> specified tree of file is introduced to ioctl.
>
> Signed-off-by: TARUISI Hiroaki
> ---
> fs/btrfs/ioctl.c | 283
> +++
> fs
Hi all
when I tried to reproduce the bug highlighted by Andrew, I discovered another
bug. When I link a file from a subvolume to another, then remove the subvolume
I got a wrong link: in my test an *hard* link becomes a *soft* link
Steps to reproduce the bug:
r...@venice:/tmp/test
Hi Andrew
On Friday 11 December 2009, Andrew Lutomirski wrote:
> Hi all-
>
> I'm a bit mystified by snapshots. I think that there are some bugs in
> btrfsctl at least (or maybe its documentation). There's definitely at
> least one bug in the kernel.
>
> Here's some commands I just tried (vanil
Johannes Hirte wrote:
Am Freitag 11 Dezember 2009 16:27:54 schrieb Edward Shishkin:
Johannes Hirte wrote:
Am Freitag 11 Dezember 2009 12:17:29 schrieb Edward Shishkin:
Johannes Hirte wrote:
Am Freitag 11 Dezember 2009 00:15:46 schrieb Johannes Hirte:
Am Fre
Hi all-
I'm a bit mystified by snapshots. I think that there are some bugs in
btrfsctl at least (or maybe its documentation). There's definitely at
least one bug in the kernel.
Here's some commands I just tried (vanilla 2.6.32, btrfs-progs from
git today. "test" is a brand-new empty btrfs file
Am Freitag 11 Dezember 2009 16:27:54 schrieb Edward Shishkin:
> Johannes Hirte wrote:
> > Am Freitag 11 Dezember 2009 12:17:29 schrieb Edward Shishkin:
> >> Johannes Hirte wrote:
> >>> Am Freitag 11 Dezember 2009 00:15:46 schrieb Johannes Hirte:
> Am Freitag 25 September 2009 00:06:23 schrieb
Good efficiency or good stableness, it's a question.
Every cow file system a block update will cause update to the block
point to it and recursively to root. Thus these file systems will
write more blocks than in-place update file systems(like ext3). This
cannot be avoided.
But do have some techn
Johannes Hirte wrote:
Am Freitag 11 Dezember 2009 12:17:29 schrieb Edward Shishkin:
Johannes Hirte wrote:
Am Freitag 11 Dezember 2009 00:15:46 schrieb Johannes Hirte:
Am Freitag 25 September 2009 00:06:23 schrieb Edward Shishkin:
Hello everyone.
Hi all,
I've seen a lot of interesting ideas on your wiki page.
http://btrfs.wiki.kernel.org/index.php/Project_ideas
I'd like to see one more:
combining some features (snapshot, Incremental backups, Hybrid Storage, NFS
support ) could lead to a file system for Laptops with disconnected mode
sup
Am Freitag 11 Dezember 2009 12:17:29 schrieb Edward Shishkin:
> Johannes Hirte wrote:
> > Am Freitag 11 Dezember 2009 00:15:46 schrieb Johannes Hirte:
> >
> >> Am Freitag 25 September 2009 00:06:23 schrieb Edward Shishkin:
> >>
> >>> Hello everyone.
> >>>
> >> ...
> >>
> >>
> >>
2009/12/11 Hu Ruihuan :
> Hi all,
> I am puzzled about a question, everytime when btrfs_writepage is
> called, whethe the noeds in every levels of the fs tree will be
> updated. This is the case as I read in the code, but if this case,
> whether it will give rise to the low efficiency?
> Thanks!
Hi all,
I am puzzled about a question, everytime when btrfs_writepage is
called, whethe the noeds in every levels of the fs tree will be
updated. This is the case as I read in the code, but if this case,
whether it will give rise to the low efficiency?
Thanks!
--
To unsubscribe from this list:
Johannes Hirte wrote:
Am Dienstag 03 November 2009 01:59:39 schrieb Edward Shishkin:
Johannes Hirte wrote:
Why is the btrfs code
dealing with network devices at all?
Why not? :)
I don't see the possiblity to get a btrfs filesystem this way. So as far as I
understand thi
Johannes Hirte wrote:
Am Freitag 11 Dezember 2009 00:15:46 schrieb Johannes Hirte:
Am Freitag 25 September 2009 00:06:23 schrieb Edward Shishkin:
Hello everyone.
...
The following patches are for Fedora 10(**).
The distro-independent package will be put to kernel.org a bi
19 matches
Mail list logo
