Hello,
I added a new disk into our RAID5 array, it looks like this:
md2 : active raid5 sdd4[3] sde4[4] sda4[0] sdc4[2] sdb4[1]
3767274240 blocks level 5, 64k chunk, algorithm 2 [5/5] [U]
# btrfs fi sh
Label: none uuid: 5534d2e7-be31-49c7-8ab7-90c5ab8afe18
Total devices 1 FS
Hello again,
OK I found it (randomly) on the wiki:
btrfs filesystem resize 3:max /home
Seems like btrfs help is not up-to-date and the wiki is...
Thank you again
Lubos
Lubos Kolouch, Wed, 04 May 2011 08:31:30 +:
Hello,
I added a new disk into our RAID5 array, it looks like this:
cac...@quantum-sci.com wrote (ao):
I would be happy to upgrade grub, but the package management system is
jammed because of this.
Put an exit on top of /etc/kernel/postrm.d/zz-update-grub and try again.
Install grub-pc 1.99~rc1-13 from Sid.
Hi Park,
Thanks a lot for the response.
It seems similar with TRIM. So how about to consider TRIM
implementation or extend it?
Yes, file system set REQ_DISCARD flag to notify block device driver to execute
TRIM.
And I noticed there's already a flag REQ_META used for file system meta data.
But
Am 2011-05-04 04:18, schrieb Fajar A. Nugraha:
could you give me some advice how to debug/report this specific
problem more
precise?
If it's not reproducible then I'd suspect it'd be hard to do.
the last working snapshot is from 2011-05-02-17:13. i can reproduce this
file system corruption
Yes, I have been working on some changes that allow us to tag bios and
pass the information out to storage. These patches have been on the back
burner for a while due to other commitments. But I'll dig them out and
post them later. We just discussed them a couple of weeks ago at the
Linux Storage
On Wed, May 04, 2011 at 01:39:46PM +0200, Martin Schitter wrote:
and the 'nodatasum' option should also ignore csum issues.-- isn't it?
No, nodatasum will prevent newly-written data from being
checksummed. However, if a checksum already exists (because the data
was written to a filesystem
On Wed, May 4, 2011 at 5:39 AM, Martin Schitter m...@mur.at wrote:
Am 2011-05-04 04:18, schrieb Fajar A. Nugraha:
could you give me some advice how to debug/report this specific
problem more
precise?
If it's not reproducible then I'd suspect it'd be hard to do.
the last working snapshot
Am 2011-05-04 13:51, schrieb cwillu:
that looks very unplausible to me. there is an RAID1 layer beneath btrfs in
our setup and i don't see any errors there.
That doesn't rule out the possibility of corruption when it was
written in the first place, or some similar problem that the raid1
Excerpts from Martin Schitter's message of 2011-05-03 17:56:32 -0400:
since my last debian kernel-update to 2.6.38-2-amd64 i got troubles with
csum failures. it's a volume full of huge kvm-images on md-RAID1 and
LVM, so i used the mount options: 'noatime,nodatasum' to maximize the
Hey Martin,
On 05/04/11 13:39, Martin Schitter wrote:
Usually checksum errors is early sign of hardware failure (most
common are disk or power supply).
that looks very unplausible to me. there is an RAID1 layer beneath btrfs
in our setup and i don't see any errors there.
Is the btrfs RAID1
Am 2011-05-04 14:31, schrieb Kaspar Schleiser:
Is the btrfs RAID1 itself inside a virtual machine? I've had data
corruption with virtio block devices 1TB on early squeeze kernels.
no -- it's on the (native) host side. and we use a very actual kernel
from debian 'testing' (2.6.38-2).
martin
Am 2011-05-04 14:39, schrieb Chris Mason:
What OS is inside these virtual machines? The btrfs unstable tree has
some fixes for windows based OSes.
we have only linux guests of different flavor, no windows guests.
both corruptions during this last weeks belong to different virtual
block
When encountering an EIO while reading from a nodatasum extent, we
insert an error record into the inode's failure tree.
btrfs_readpage_end_io_hook returns early for nodatasum inodes. We'd
better clear the failure tree in that case, otherwise the kernel
complains about
BUG extent_state:
On 05/04/2011 10:26 AM, wh...@gmx.com wrote:
Hi all,
Here's a traceback from a failed attempt to mount a btrfs in lvm in luks
filesystem.
Note that if I mount it readonly it mounts successfully (haven't tried to
recover any data as I have recent backups).
Yesterday I defragmented both / and
On 2011-05-04, at 5:45 AM, Gao, Yunpeng yunpeng@intel.com wrote:
Yes, I have been working on some changes that allow us to tag bios and
pass the information out to storage. These patches have been on the back
burner for a while due to other commitments. But I'll dig them out and
post them
In count_range_bits we are adjusting total_bytes based on the range we are
searching for, but we don't adjust the range start according to the range we are
searching for, which makes for weird results. For example, if the range
[0-8192]
is set DELALLOC, but I search for 4096-8192, I will get
Josef Bacik wrote:
On 04/27/2011 02:43 PM, Jim Schutt wrote:
Hi,
I'm not sure if they matter, but I got these warnings on
one of the machines I'm using as a Ceph OSD server:
[ 1806.549469] [ cut here ]
[ 1806.554593] WARNING: at fs/btrfs/extent-tree.c:5790
Chris Mason chris.ma...@oracle.com writes:
Mounting the filesystem read-only from /dev/sdd1 fails, but
succeeds from /dev/sdc1... after about 4855 parent transid
verification failures.
kernel: [ 293.827069] Btrfs loaded
kernel: [ 293.828014] device fsid
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. So we have
-SEEK_HOLE: this moves the file pos to the nearest hole in the file from
In order to handle SEEK_HOLE/SEEK_DATA we need to implement our own llseek.
Basically for the normal SEEK_*'s we will just defer to the generic helper, and
for SEEK_HOLE/SEEK_DATA we will use our fiemap helper to figure out the nearest
hole or data. Currently this helper doesn't check for
Hi,
several time ago I posted a patch which addressed this lack of
documentation [1]. Unfortunately when I revised this patch I missed this
chunk, and now Chris merged the last (uncompleted) revision.
So now I am publish a new patch which address this issue.
Chris, if you want you can pull it
On 05/04/2011 01:43 PM, wh...@gmx.com wrote:
On Wednesday 04 May 2011 16:46:44 Josef Bacik wrote:
On 05/04/2011 10:26 AM, wh...@gmx.com wrote:
Hi all,
Here's a traceback from a failed attempt to mount a btrfs in lvm in luks
filesystem.
Note that if I mount it readonly it mounts successfully
On Wed, 04 May 2011 13:58:39 EDT, Josef Bacik said:
-SEEK_HOLE: this moves the file pos to the nearest hole in the file from the
given position.
Nearest, or next? Solaris defines it as next, for a good reason - otherwise
you can get stuck in a case where the nearest hole is back towards the
On Wed, 04 May 2011 15:10:20 EDT, Josef Bacik said:
Yeah sorry the log says nearest but the code says next, if you look
at it thats how it works. Thanks,
Oh good - the changelog is usually easier to fix than the code is. :)
Probably want to fix the changelog before it gets committed, as
On 05/04/2011 03:20 PM, valdis.kletni...@vt.edu wrote:
On Wed, 04 May 2011 15:10:20 EDT, Josef Bacik said:
Yeah sorry the log says nearest but the code says next, if you look
at it thats how it works. Thanks,
Oh good - the changelog is usually easier to fix than the code is. :)
Probably
On Wed, 04 May 2011 13:58:39 EDT, Josef Bacik said:
+#define SEEK_HOLE3 /* seek to the closest hole */
+#define SEEK_DATA4 /* seek to the closest data */
Comments here need nearest/next fixing as well - otherwise the ext[34] crew may
actually implement the commented
On 05/04/2011 03:31 PM, valdis.kletni...@vt.edu wrote:
On Wed, 04 May 2011 13:58:39 EDT, Josef Bacik said:
+#define SEEK_HOLE 3 /* seek to the closest hole */
+#define SEEK_DATA 4 /* seek to the closest data */
Comments here need nearest/next fixing as well - otherwise
This is my very rough tester for testing seek_hole/seek_data. Please look over
it and make sure we all agree that the semantics are correct. My btrfs patch
passes with this and ext3 passes as well. I still have to added fallocate() to
it, but for now this seems to cover most of the corner
On 05/04/2011 02:10 PM, Josef Bacik wrote:
On 05/04/2011 03:04 PM, valdis.kletni...@vt.edu wrote:
On Wed, 04 May 2011 13:58:39 EDT, Josef Bacik said:
-SEEK_HOLE: this moves the file pos to the nearest hole in the file
from the
given position.
Nearest, or next? Solaris defines it as next,
On 05/04/2011 04:54 PM, Dave Kleikamp wrote:
The comments in fs.h say closest. You may want to change them to
next as well.
Sorry. Missed some of the replies before I responded. Already addressed.
Shaggy
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of
31 matches
Mail list logo
