Hi all,
Filling a dm/lvm snapshot triggered this btrfs WARNING, kernel is 4.0-rc3+
I'm working a xfstests case but this simple script could reproduce
--- cut ---
#!/bin/bash
dev=/dev/sda5
mnt=/mnt/test
vgname=testvg
lvname=testlv
snap=snap
vgcreate -f $vgname $dev
lvcreate -L 256M -n $lvname $v
don fisher posted on Thu, 19 Mar 2015 18:49:32 -0700 as excerpted:
> Any thoughts on stability of the IDs across boots?
Btrfs subvolIDs are a property of the btrfs and thus stable across boots.
(They're actually the root-tree ID, with ID=5 the main root tree for the
entire filesystem, various o
Chris Murphy posted on Thu, 19 Mar 2015 13:09:06 -0600 as excerpted:
> Erkki's cp --reflink idea is a good one. I've often wondered if it's a
> good idea, and possible, to eventually make --reflink the default
> behavior with Btrfs copies (I think some things probably first need
> enhancement like
On Thu, Mar 19, 2015 at 8:34 PM, don fisher wrote:
> Thanks. I will try that. How does the mount distinguish between /srv and
> /usr11/srv if the subvol=srv is the same for both? It appears to work, for
> when I do a df the sizes are different. I guess it can tell from the UUID of
> / as opposed
On 03/19/2015 07:15 PM, Chris Murphy wrote:
On Thu, Mar 19, 2015 at 7:49 PM, don fisher wrote:
My rot
is mounted at /usr11. I tried:
UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/srv btrfs
subvol=usr11/srv 0 0
but /usr11/srv did not mount. I replaced the number and it did mount. Woul
On Thu, Mar 19, 2015 at 7:49 PM, don fisher wrote:
> My rot
> is mounted at /usr11. I tried:
>
> UUID=26d63d99-92f4-4a49-878b-236f5e88af69 /usr11/srv btrfs
> subvol=usr11/srv 0 0
>
> but /usr11/srv did not mount. I replaced the number and it did mount. Would
> like to use string like you sug
OK will do.
Thanks, Anand
On 03/20/2015 02:55 AM, David Sterba wrote:
On Tue, Mar 10, 2015 at 06:38:43AM +0800, Anand Jain wrote:
by using the kobject_move()
Then you should add the kobject_move patch to this patchset as well,
with Greg's ack.
--
To unsubscribe from this list: send t
# btrfs sub list /
ID 257 gen 1703 top level 5 path root
ID 258 gen 1662 top level 5 path home
ID 259 gen 1681 top level 5 path boot
ID 262 gen 1629 top level 257 path var/lib/machines
To mount machines, either
subvol=root/var/lib/machines
OR
subvolid=262
Why root/var/lib/machines? Because var/
convert-tests now test both 4096 and 16384 nodesizes.
Signed-off-by: Sebastian Thorarensen
---
tests/convert-tests.sh | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/tests/convert-tests.sh b/tests/convert-tests.sh
index 6094287..3d912f3 100644
--- a/tests/c
Allow btrfs-convert to use nodesizes other than 4096. It defaults to
max(16384, pagesize), like mkfs.
Signed-off-by: Sebastian Thorarensen
---
Documentation/btrfs-convert.txt |4 +++
btrfs-convert.c | 60 ++-
2 files changed, 57 insertion
Move the constant DEFAULT_MKFS_LEAF_SIZE to utils.h and rename it to
BTRFS_MKFS_DEFAULT_NODE_SIZE for consistency. Move the function
check_leaf_or_node_size to utils.c and rename it to
check_node_or_leaf_size.
Signed-off-by: Sebastian Thorarensen
---
mkfs.c | 26 ++
ut
check_node_or_leaf_size in utils.c now prints 'nodesize (or leafsize)'
instead of 'leafsize (or nodesize)' in the error messages, in order to
be less confusing for the user, as leafsize in mkfs is deprecated.
'ERROR: ' is also prepended to be consistent with other error messages.
Signed-off-by: Se
Changes since v1:
* Split patch into smaller patches
* btrfs-convert and mkfs now shares check_node_or_leaf_size
* Rebased onto latest v3.19.x
Sebastian Thorarensen (4):
btrfs-progs: mkfs: Move out some nodesize code
btrfs-progs: Fix msgs in check_node_or_leaf_size
btrfs-progs: btrfs-conv
On Thu, Mar 19, 2015 at 5:31 PM, don fisher wrote:
> I was happy until I tried to perform an ls on /usr11/tmp and found that it
> contained the root file system, all the /usr11 files present. My plan had
> been to rsync these two systems, from / to /usr11. If I umount /usr1/tmp
> subvolume and ls
I am new to btrfs, being introduced under openSuse 3.2 as the root file
system. In the past I always made backups of my disks using rsync. I now
have two versions of the OS on the same system. I was trying to mount
the second btrfs system as well as the first. I edited my /etc/fstab
(attached)
On Thu, Mar 19, 2015 at 5:06 PM, G. Richard Bellamy
wrote:
> When I upgrade to the 3.19.2 Kernel I get a deadlocked boot:
> INFO: task mount:302 blocked for more than 120 seconds.
> INFO: task btrfs-transacti:329 blocked for more than 120 seconds.
If you boot single user is it semi-responsive eno
On Thu, Mar 19, 2015 at 04:31:08PM -0400, Josef Bacik wrote:
> This creates a new target that is meant for file system developers to test
> file
> system integrity at particular points in the life of a file system.
Hi Josef, just a quick drive-by review for stuff that jumps out at me..
> + a
When I upgrade to the 3.19.2 Kernel I get a deadlocked boot:
INFO: task mount:302 blocked for more than 120 seconds.
INFO: task btrfs-transacti:329 blocked for more than 120 seconds.
I have an LTS Kernel at 3.14.35 that also fails to boot with the same behavior.
My 3.18.6 works just fine.
-rb
--
Filipe David Manana schrieb:
> On Thu, Mar 19, 2015 at 1:21 PM, David Sterba wrote:
>> On Wed, Mar 18, 2015 at 03:23:50PM +0100, Martin Steigerwald wrote:
>>> It explains that having a correct hardlink number for directory is not
>>> mandatory, but it doesn´t explain why BTRFS always has 1 in th
On Thu, Mar 19, 2015 at 1:21 PM, David Sterba wrote:
> On Wed, Mar 18, 2015 at 03:23:50PM +0100, Martin Steigerwald wrote:
>> It explains that having a correct hardlink number for directory is not
>> mandatory, but it doesn´t explain why BTRFS always has 1 in there instead
>> of the actual count o
On Thu, Mar 05, 2015 at 10:17:14AM +, Filipe David Manana wrote:
> On Thu, Mar 5, 2015 at 2:56 AM, Zygo Blaxell
> wrote:
> > rsync seems to get stuck just by reading the same file that extent-same is
> > acting upon.
> >
> > Mar 4 21:35:08 sneezy kernel: [89798.758960] INFO: task rsync:7425 b
This patch adds the supporting code for using the dm-log-writes target. The
bash stuff is similar to the dmflakey code, it just gives us functions to build
and tear down a dm-log-writes target. We add a new LOGWRITES_DEV variable to
take in the device we will use as the log and add checks for tha
This test runs fsstress+balance+defrag and then replays every FUA in the log and
mounts, scrubs and then fscks the fs to make sure it does the balance recovery
properly. Thanks,
Signed-off-by: Josef Bacik
---
tests/btrfs/083 | 135
tests/
Here are my patches for adding the dm-log-writes target to the kernel and the
supporting xfstests to go along with it. The dm patch has a pretty detailed
documentation file to describe the methodology behind the target and how to use
it. The xfstest that is generic has been tested on btrfs, xfs a
This creates a new target that is meant for file system developers to test file
system integrity at particular points in the life of a file system. We capture
all write requests and the data and log the requests and the data to a separate
device for later replay. There is a userspace utility to d
On Wed, Mar 18, 2015 at 5:22 PM, K Richard Pixley
wrote:
> Most of the uses I have for btrfs involve fairly dynamic use of snapshots,
> typically by non-root users.
Another thing. Some distros behave this way:
chris@linux-6gc0:~> btrfs sub list /
Absolute path to 'btrfs' is '/usr/sbin/btrfs', so
On Tue, Mar 10, 2015 at 06:38:18AM +0800, Anand Jain wrote:
> This patch set will provide a framework and help to create attributes
> from the structure btrfs_fs_devices which are available even before
> fs_info is created. So by moving the parent kobject super_kobj from
> fs_info to btrfs_fs_devic
On Tue, Mar 10, 2015 at 06:38:43AM +0800, Anand Jain wrote:
> by using the kobject_move()
Then you should add the kobject_move patch to this patchset as well,
with Greg's ack.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.ker
On Sun, Mar 1, 2015 at 5:20 PM, Chandan Rajendra
wrote:
> The test case passes file offsets which don't align with 64K block size. This
> causes btrfs_ioctl_clone() to return with -EINVAL. Fix this by using offsets
> which are multiples of 64k.
>
> Signed-off-by: Chandan Rajendra
Reviewed-by: Fil
On Fri, Feb 27, 2015 at 04:24:22PM +0800, Qu Wenruo wrote:
> Although we have qgroup level check in btrfs-progs, it's not enough
> since other programe may still call ioctl directly not using
> btrfs-progs. For example, systemd.
>
> But it's btrfs-progs to be blame since we don't provide a
> full-
On Wed, Mar 18, 2015 at 04:36:17PM +0100, Zoltán Halassy wrote:
> Is it safe to use do something like this:
>
> # btrfs filesystem resize 100m /mnt/something && lvreduce -f -L100M
> /dev/somevg/somelv
>
> as in, when the first command exits with 0 status, is the filesystem
> already resized? I me
On Wed, Mar 18, 2015 at 03:23:50PM +0100, Martin Steigerwald wrote:
> It explains that having a correct hardlink number for directory is not
> mandatory, but it doesn´t explain why BTRFS always has 1 in there instead
> of the actual count of hardlinks. Is this an performance optimization for
> B
On Tue, Mar 17, 2015 at 04:37:59PM -0400, Josef Bacik wrote:
> I've changed all of these a whole bunch recently, I think I've gotten all the
> issues worked out, please review/test to make sure there's not some other
> fucking corner I've missed. Thanks,
The dirty_bgs assert is gone and fstests h
K Richard Pixley writes:
> But as a user level facility, I want to be able to snapshot before
> making a change to a tree full of source code and (re)building it all
> over again. I may want to keep my new build, but I may want to flush
> it and return to known good state.
You may want to check
34 matches
Mail list logo
