Thanks for all the info guys.
I ran some tests on the latest 3.12.8 kernel. I set up 3 1GB files and attached
them to /dev/loop{1..3} and created a BTRFS RAID 5 volume with them.
I copied some data (from dev/urandom) into two test files and got their MD5
sums and saved them to a text file.
I
--
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 http://vger.kernel.org/majordomo-info.html
This testscript creates reflinks to files on different subvolumes,
overwrites the original files and reflinks, and moves reflinked files
between subvolumes.
Signed-off-by: Koen De Wit koen.de@oracle.com
---
Originally submitted as test 302, btrfs/316
diff --git a/tests/btrfs/030
On 2014-01-21 01:42, Sandy McArthur wrote:
On Mon, Jan 20, 2014 at 7:20 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2014-01-16 14:23, Toggenburger Lukas wrote:
3. Improving subvolume handling regarding taking recursive snapshots (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have just recently replaced two 750 GB disks with two 1 TB disks. I
used the replace command to do so, aka btrfs replace start /dev/sdX
/dev/sdY /mountpoint. Each replacement went smoothly, with no errors
reporting. I'm positive that the source
Hello Kyle,
you will probably have to tell btrfs to use the complete devices.
Checkout btrfs filesystem resize. There are cases when one does not
want to grow the used space on a replacement disk automatically, e.g.
when the disk is to be replaced with a smaller disk again, so this is
not a bug.
Hi all,
I just noticed a mismatch between statfs.f_bfree and statfs.f_bavail, i.e.
(squeeze)fslab2:~# ./statfs /data/fhgfs/storage1/
/data/fhgfs/storage1/: avail: 3162112 free: 801586610176
(with
uint64_t avail = statbuf.f_bavail * statbuf.f_bsize;
uint64_t free =
Commit Btrfs-progs: make send/receive compatible with older kernels
adds code that will become deprecated, let's clearly mark it in the
sources.
CC: Stefan Behrens sbehr...@giantdisaster.de
CC: Wang Shilong wangsl.f...@cn.fujitsu.com
Signed-off-by: David Sterba dste...@suse.cz
---
send-utils.c |
On Sat, Jan 18, 2014 at 12:58:00PM +0800, Wang Shilong wrote:
Steps to reproduce:
# mkfs.btrfs -f /dev/sda8
# mount /dev/sda8 /mnt
# btrfs sub snapshot -r /mnt /mnt/snap1
# btrfs sub snapshot -r /mnt /mnt/snap2
# btrfs send /mnt/snap1 -p /mnt/snap2 -f /mnt/1
# dmesg
The problem is
On Sat, Jan 18, 2014 at 4:58 AM, Wang Shilong
wangsl.f...@cn.fujitsu.com wrote:
Steps to reproduce:
# mkfs.btrfs -f /dev/sda8
# mount /dev/sda8 /mnt
# btrfs sub snapshot -r /mnt /mnt/snap1
# btrfs sub snapshot -r /mnt /mnt/snap2
# btrfs send /mnt/snap1 -p /mnt/snap2 -f /mnt/1
# dmesg
Hello Filipe,
On Sat, Jan 18, 2014 at 4:58 AM, Wang Shilong
wangsl.f...@cn.fujitsu.com wrote:
Steps to reproduce:
# mkfs.btrfs -f /dev/sda8
# mount /dev/sda8 /mnt
# btrfs sub snapshot -r /mnt /mnt/snap1
# btrfs sub snapshot -r /mnt /mnt/snap2
# btrfs send /mnt/snap1 -p /mnt/snap2 -f
On Tue, Jan 21, 2014 at 4:45 PM, Wang Shilong wangshilong1...@gmail.com wrote:
Hello Filipe,
On Sat, Jan 18, 2014 at 4:58 AM, Wang Shilong
wangsl.f...@cn.fujitsu.com wrote:
Steps to reproduce:
# mkfs.btrfs -f /dev/sda8
# mount /dev/sda8 /mnt
# btrfs sub snapshot -r /mnt /mnt/snap1
#
On Tue, Jan 21, 2014 at 07:25:43AM -0500, Austin S Hemmelgarn wrote:
On 2014-01-21 01:42, Sandy McArthur wrote:
On Mon, Jan 20, 2014 at 7:20 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2014-01-16 14:23, Toggenburger Lukas wrote:
3. Improving subvolume handling regarding
On 2014-01-21 11:52, Hugo Mills wrote:
On Tue, Jan 21, 2014 at 07:25:43AM -0500, Austin S Hemmelgarn wrote:
On 2014-01-21 01:42, Sandy McArthur wrote:
On Mon, Jan 20, 2014 at 7:20 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2014-01-16 14:23, Toggenburger Lukas wrote:
3. Improving
Graham Fleming posted on Tue, 21 Jan 2014 01:06:37 -0800 as excerpted:
Thanks for all the info guys.
I ran some tests on the latest 3.12.8 kernel. I set up 3 1GB files and
attached them to /dev/loop{1..3} and created a BTRFS RAID 5 volume with
them.
I copied some data (from dev/urandom)
Would it be reasonably accurate to say btrfs' RAID5 implementation is
likely working well enough and safe enough if you are backing up
regularly and are willing and able to restore from backup if necessary
if a device failure goes horribly wrong, then?
This is a reasonably serious question.
On Jan 21, 2014, at 10:18 AM, Jim Salter j...@jrs-s.net wrote:
Would it be reasonably accurate to say btrfs' RAID5 implementation is likely
working well enough and safe enough if you are backing up regularly and are
willing and able to restore from backup if necessary if a device failure
Thanks again for the added info; very helpful.
I want to keep playing around with BTRFSS RAID 5 and testing with it...
assuming I have a drive with bad blocks, or let's say some inconsistent parity
am I right in assuming that a) a btrfs scrub operation will not fix the stripes
with bad parity
The COMPRESS_LZOv2 incompat featue is currently not implemented, the bit
is only reserved, no point to list it in sysfs.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/sysfs.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/sysfs.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index 1a893860d66b..782374d8fd19 100644
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -202,6 +202,7 @@
David Sterba (2):
btrfs: sysfs: don't show reserved incompat feature
btrfs: sysfs: list the NO_HOLES feature
fs/btrfs/sysfs.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a
On Thu, Jan 16, 2014 at 10:32:38AM +0800, Miao Xie wrote:
Your fix makes sure that the deleted root will not get cleaned and stays
during the send. Only after it finishes it will be cleaned. Now, what if
send fails or is interrupted? There's no way to redo it. Yes the user
can be blamed
There are different values of testing and of production - in my
world, at least, they're not atomically defined categories. =)
On 01/21/2014 12:38 PM, Chris Murphy wrote:
It's for testing purposes. If you really want to commit a production
machine for testing a file system, and you're prepared
When defragging a very large file, the cluster variable can wrap its 32-bit
signed int type and become negative, which eventually gets passed to
btrfs_force_ra() as a very large unsigned long value. On 32-bit platforms,
this eventually results in an Oops from the SLAB allocator.
Change the
Hello again:
I think, I do/did have some symptoms, but I cannot exclude other reasons..
-High Load without high cpu-usage (io was the bottleneck)
-Just now: transfer from one directory to the other on the same
subvolume (from /mnt/subvol/A/B to /mnt/subvol/A) I get 1.2MB/s instead
of 60.
-For
Hello,
Yes. Here I mount the three subvolumes:
Does scrubbing the volume give any errors?
Last time I did (that was after I discovered the first errors in
btrfsck) scrub, it found no error. But I will re-check asap.
As to the error messages: I do not know how critical those are.
I
Hi
I suddenly got issues accessing a samba share and rebooted the server.
After the reboot the btrfs mount does not come up and prints the
following messages in dmesg:
[ 530.881802] btrfs: device fsid 9302fc8f-15c6-46e9-9217-951d7423927c
devid 4 transid 138602 /dev/sdt
[ 530.882734] btrfs:
Ok, I think I found the issue. The array was okay and mounted
successfully after running btrfs device scan, and the samba issue
was unrelated and had something to do with winbind integration with AD
which the reboot cured after getting the btrfs store to mount.
It has always done this
The buffer size argument passed to snprintf must account for the
trailing null byte added by snprintf, and it returns a value = then
sizeof(buffer) when the string can't fit in the buffer.
Since our buffer has a size of 64 characters, and the maximum orphan
name we can generate is 63 characters
The send operation processes inodes by their ascending number, and assumes
that any rename/move operation can be successfully performed (sent to the
caller) once all previous inodes (those with a smaller inode number than the
one we're currently processing) were processed.
This is not true when
The send operation processes inodes by their ascending number, and assumes
that any rename/move operation can be successfully performed (sent to the
caller) once all previous inodes (those with a smaller inode number than the
one we're currently processing) were processed.
This is not true when
Regression test for btrfs' incremental send feature:
1) Create several nested directories;
2) Create a read only snapshot;
3) Change the parentship of some of the deepest directories in a reverse
way, so that parents become children and children become parents;
4) Create another read only
reproducer:
mkfs.btrfs -f /dev/sdb \
mount /dev/sdb /btrfs \
btrfs dev add -f /dev/sdc /btrfs \
umount /btrfs \
wipefs -a /dev/sdc \
mount -o degraded /dev/sdb /btrfs
//above mount fails so try with RO
mount -o degraded,ro /dev/sdb /btrfs
--
sysfs: cannot create duplicate filename
The send operation processes inodes by their ascending number, and assumes
that any rename/move operation can be successfully performed (sent to the
caller) once all previous inodes (those with a smaller inode number than the
one we're currently processing) were processed.
This is not true when
The send operation processes inodes by their ascending number, and assumes
that any rename/move operation can be successfully performed (sent to the
caller) once all previous inodes (those with a smaller inode number than the
one we're currently processing) were processed.
This is not true when
The send operation processes inodes by their ascending number, and assumes
that any rename/move operation can be successfully performed (sent to the
caller) once all previous inodes (those with a smaller inode number than the
one we're currently processing) were processed.
This is not true when
with the changes that has happened since last time it was updated
Signed-off-by: Anand Jain anand.j...@oracle.com
---
INSTALL |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/INSTALL b/INSTALL
index 8ead607..a86878a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -12,7 +12,8
37 matches
Mail list logo
