On Mon, Nov 08, 2010 at 10:54:07AM +0800, Ian Kent wrote:
On Sun, 2010-11-07 at 09:51 -0500, Josef Bacik wrote:
On Sun, Nov 07, 2010 at 04:16:47PM +0900, Yoshinori Sano wrote:
This is a question I've posted on the #btrfs IRC channel today.
hyperair adviced me to contact with Josef Bacik
Excerpts from Brian Neu's message of 2010-11-06 21:08:59 -0400:
After a successful db startup, this crash was reproducible every time with db
activity, or possibly just time. The filesystem is a raid1 and even after a
reformat and restore from backup, the crash remains:
Label: slash
On Mon, 2010-11-08 at 07:42 -0500, Josef Bacik wrote:
On Mon, Nov 08, 2010 at 10:54:07AM +0800, Ian Kent wrote:
On Sun, 2010-11-07 at 09:51 -0500, Josef Bacik wrote:
On Sun, Nov 07, 2010 at 04:16:47PM +0900, Yoshinori Sano wrote:
This is a question I've posted on the #btrfs IRC channel
On Mon, Nov 08, 2010 at 10:06:13PM +0800, Ian Kent wrote:
On Mon, 2010-11-08 at 07:42 -0500, Josef Bacik wrote:
On Mon, Nov 08, 2010 at 10:54:07AM +0800, Ian Kent wrote:
On Sun, 2010-11-07 at 09:51 -0500, Josef Bacik wrote:
On Sun, Nov 07, 2010 at 04:16:47PM +0900, Yoshinori Sano wrote:
Hello list.
I've been working on my MSc thesis and I believe such a time came when it will
cross paths with BTRFS.
However, I have a couple of standing questions I haven't been able do answer,
even though having read Ohad Rodeh's paper, most of the wiki's documentation,
after looking to
I've been puzzled why I see a flood of ENOENT returned upon rename during
Fedora 13 and 14's GDM session.
The case is of course handled by your recent patch which is in upstream and
btrfs-unstable, but I thought
doing a log look-up always fail is inefficient so I checked the code path that
On Sun, Nov 07 2010 at 6:05pm -0500,
Andi Kleen a...@firstfloor.org wrote:
On Sun, Nov 07, 2010 at 10:39:23PM +0100, Milan Broz wrote:
On 11/07/2010 08:45 PM, Andi Kleen wrote:
I read about barrier-problems and data getting to the partition when
using dm-crypt and several layers so I
On Mon, 2010-11-08 at 09:15 -0500, Josef Bacik wrote:
On Mon, Nov 08, 2010 at 10:06:13PM +0800, Ian Kent wrote:
On Mon, 2010-11-08 at 07:42 -0500, Josef Bacik wrote:
On Mon, Nov 08, 2010 at 10:54:07AM +0800, Ian Kent wrote:
On Sun, 2010-11-07 at 09:51 -0500, Josef Bacik wrote:
On
There are lots of places where we do dentry-d_parent-d_inode without holding
the dentry-d_lock. This could cause problems with rename. So instead use
dget_parent where we can, or in some cases we don't even need to use
dentry-d_parent-d_inode since we get the inode of the dir passed to us from
Hi,
Got an oops last week while rebalancing that seems to have left me with
a corrupted btrfs. Kernel was ~2.6.36 + Transparent hugetlb patchset +
small misc. patchs.
I tried my last reliable 2.6.35 based kernel without the transparent
hugetlb patchset and the btrfs was not mountable there
On Monday, 08 November, 2010, João Eduardo Luís wrote:
Hello list.
[...]
Basically, I need to be aware how the COW works in BTRFS, and what it may
allow one to achieve. Questions follow.
1) Is COW only used when creating or updating a file? While testing BTRFS,
using 'btrfs subvolume
Excerpts from Shane Shrybman's message of 2010-11-08 12:10:57 -0500:
Hi,
Got an oops last week while rebalancing that seems to have left me with
a corrupted btrfs. Kernel was ~2.6.36 + Transparent hugetlb patchset +
small misc. patchs.
Have you tried the 2.6.36 + the btrfs unstable git
Excerpts from Mike Snitzer's message of 2010-11-08 09:58:09 -0500:
On Sun, Nov 07 2010 at 6:05pm -0500,
Andi Kleen a...@firstfloor.org wrote:
On Sun, Nov 07, 2010 at 10:39:23PM +0100, Milan Broz wrote:
On 11/07/2010 08:45 PM, Andi Kleen wrote:
I read about barrier-problems and data
[ sorry for breaking the thread, I'm replying from the archives, I was
unsubbed after a mail server issue and didn't notice till now... ]
On Sat, Oct 30, 2010 at 07:44:35PM +0200, Goffredo Baroncelli wrote:
balance- info on balancing
Hugo Mills wrote:
For
Hi all,
the enclosed patch is a second attempt to export some information from btrfs
filesystem through the sysfs interface.
At the moment there are two kinds of information available. The ones related
to the devices and the ones related to the filesystems.
Before explaining the sysfs
Excerpts from Itaru Kitayama's message of 2010-11-08 09:27:51 -0500:
I've been puzzled why I see a flood of ENOENT returned upon rename during
Fedora 13 and 14's GDM session.
The case is of course handled by your recent patch which is in upstream and
btrfs-unstable, but I thought
On Mon, 2010-11-08 at 12:55 -0500, Chris Mason wrote:
Excerpts from Shane Shrybman's message of 2010-11-08 12:10:57 -0500:
Hi,
Got an oops last week while rebalancing that seems to have left me with
a corrupted btrfs. Kernel was ~2.6.36 + Transparent hugetlb patchset +
small misc.
This patch just makes ocfs2 use its UNRESERVP ioctl when we get the hole punch
flag in fallocate. I didn't test it, but it seems simple enough. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/ocfs2/file.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git
This patch simply allows XFS to handle the hole punching flag in fallocate
properly. I've tested this with a little program that does a bunch of random
hole punching with FL_KEEP_SIZE and without it to make sure it does the right
thing. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
Excerpts from Brian Neu's message of 2010-11-08 12:52:21 -0500:
Ok, could you please take a picture of the crash? We'll need all the lines.
I really hope you mean picture as in photo of the screen, and I'm not
committing an egregious list faux pas by attaching this.
No, this is perfect ;)
Hole punching has already been implemented by XFS and OCFS2, and has the
potential to be implemented on both BTRFS and EXT4 so we need a generic way to
get to this feature. The simplest way in my mind is to add FALLOC_FL_PUNCH_HOLE
to fallocate() since it already looks like the normal fallocate()
Gfs2 doesn't have the ability to punch holes yet, so make sure we return
EOPNOTSUPP if we try to use hole punching through fallocate. This support can
be added later. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/gfs2/ops_inode.c |4
1 files changed, 4 insertions(+), 0
Ext4 doesn't have the ability to punch holes yet, so make sure we return
EOPNOTSUPP if we try to use hole punching through fallocate. This support can
be added later. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/ext4/extents.c |4
1 files changed, 4 insertions(+), 0
Excerpts from Shane Shrybman's message of 2010-11-08 15:39:25 -0500:
On Mon, 2010-11-08 at 12:55 -0500, Chris Mason wrote:
Excerpts from Shane Shrybman's message of 2010-11-08 12:10:57 -0500:
Hi,
Got an oops last week while rebalancing that seems to have left me with
a corrupted
On Mon, 2010-11-08 at 16:04 -0500, Chris Mason wrote:
Excerpts from Shane Shrybman's message of 2010-11-08 15:39:25 -0500:
On Mon, 2010-11-08 at 12:55 -0500, Chris Mason wrote:
Excerpts from Shane Shrybman's message of 2010-11-08 12:10:57 -0500:
Hi,
Got an oops last week while
(sorry for sending twice)
On Mon, Nov 08, 2010 at 02:23:13PM +, João Eduardo Luís wrote:
Basically, I need to be aware how the COW works in BTRFS, and what it may
allow one to achieve. Questions follow.
From your questions, you don't seem to understand CoW. CoW is basically
an
2010/11/8 Josef Bacik jo...@redhat.com:
On Mon, Nov 08, 2010 at 10:17:50PM +0900, Yoshinori Sano wrote:
To reduce the number of such BUG_ON usages, the code will be more robust,
which results in increasing the number of Btrfs production use.
(This is one of the way, off course.)
But, as you
On 09/11/10 09:45, Sean Bartell wrote:
No, unless the user request a snapshot. I'm assuming you're not talking
about tools like PhotoRec, that try to reassemble files from whatever
disk data looks valid.
It may be that he has confused it with nilfs which does have
automatic periodic
Great, this is a known bug in the O_DIRECT code. I'll fix it up
tomorrow morning.
The problem is that we're allowing bios that are too large for btrfs to
deal with. It doesn't show any corruption in the FS.
-chris
Excerpts from Brian Neu's message of 2010-11-08 17:50:17 -0500:
No, this is
On Mon, Nov 08, 2010 at 03:32:02PM -0500, Josef Bacik wrote:
Hole punching has already been implemented by XFS and OCFS2, and has the
potential to be implemented on both BTRFS and EXT4 so we need a generic way to
get to this feature. The simplest way in my mind is to add
FALLOC_FL_PUNCH_HOLE
On Mon, Nov 08, 2010 at 03:32:03PM -0500, Josef Bacik wrote:
This patch simply allows XFS to handle the hole punching flag in fallocate
properly. I've tested this with a little program that does a bunch of random
hole punching with FL_KEEP_SIZE and without it to make sure it does the right
On Mon, Nov 8, 2010 at 5:33 PM, Leonidas Spyropoulos
artafi...@gmail.com wrote:
While on Ubuntu 10.10 I cannot get defragment working.
ing...@selene:~$ btrfs filesystem defragment /media/Data/
ioctl failed on /media/Data/ ret -1 errno 1
total 1 failures
...
Is it implemented on kernel
On Tue, Nov 09, 2010 at 12:22:54PM +1100, Dave Chinner wrote:
On Mon, Nov 08, 2010 at 03:32:03PM -0500, Josef Bacik wrote:
This patch simply allows XFS to handle the hole punching flag in fallocate
properly. I've tested this with a little program that does a bunch of
random
hole
On Tue, Nov 09, 2010 at 12:12:22PM +1100, Dave Chinner wrote:
On Mon, Nov 08, 2010 at 03:32:02PM -0500, Josef Bacik wrote:
Hole punching has already been implemented by XFS and OCFS2, and has the
potential to be implemented on both BTRFS and EXT4 so we need a generic way
to
get to this
On Tue, Nov 09, 2010 at 12:12:22PM +1100, Dave Chinner wrote:
Hole punching was not included originally in fallocate() for a
variety of reasons. IIRC, they were along the lines of:
1 de-allocating of blocks in an allocation syscall is wrong.
People wanted a new syscall for this
On Mon, 2010-11-08 at 09:22 +0200, Albert Strasheim wrote:
Hello all
I did some experiments on Fedora 14 with 2.6.35.6, running mkfs.btrfs
followed by a mount in parallel on 24 disks.
This seems to crash reliably.
I reported the bug to Fedora here:
On Mon, Nov 08, 2010 at 09:05:09PM -0500, Josef Bacik wrote:
On Tue, Nov 09, 2010 at 12:22:54PM +1100, Dave Chinner wrote:
On Mon, Nov 08, 2010 at 03:32:03PM -0500, Josef Bacik wrote:
This patch simply allows XFS to handle the hole punching flag in fallocate
properly. I've tested this
On Mon, Nov 08, 2010 at 10:30:38PM -0500, Ted Ts'o wrote:
On Tue, Nov 09, 2010 at 12:12:22PM +1100, Dave Chinner wrote:
Hole punching was not included originally in fallocate() for a
variety of reasons. IIRC, they were along the lines of:
1 de-allocating of blocks in an allocation
Hi,
I received the message: btrfs: unlinked 34 orphans
Just out of couriosity: what does it mean ?
Thanks in advance
Bye,
David Arendt
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at
2010/11/8 Josef Bacik jo...@redhat.com:
On Mon, Nov 08, 2010 at 10:54:07AM +0800, Ian Kent wrote:
On Sun, 2010-11-07 at 09:51 -0500, Josef Bacik wrote:
On Sun, Nov 07, 2010 at 04:16:47PM +0900, Yoshinori Sano wrote:
This is a question I've posted on the #btrfs IRC channel today.
hyperair
On Tue, 2010-11-09 at 12:10 +0800, Ian Kent wrote:
On Mon, 2010-11-08 at 09:22 +0200, Albert Strasheim wrote:
Hello all
I did some experiments on Fedora 14 with 2.6.35.6, running mkfs.btrfs
followed by a mount in parallel on 24 disks.
This seems to crash reliably.
I reported
41 matches
Mail list logo
