Le lundi 10 mars 2014 02:16:01 vous avez écrit :
Does the filesystem pass the btrfsck?
If not, would you please try btrfsck first?
It passes scrub with 0 errors... Do I need to bring it offline to pass btrfsck
anyway ?
--
Swâmi Petaramesh sw...@petaramesh.org http://petaramesh.org PGP
On Mon, 10 Mar 2014 08:25:26 +0100, Swâmi Petaramesh wrote:
Le lundi 10 mars 2014 02:16:01 vous avez écrit :
Does the filesystem pass the btrfsck?
If not, would you please try btrfsck first?
It passes scrub with 0 errors... Do I need to bring it offline to pass btrfsck
anyway ?
Better check
Le lundi 10 mars 2014 07:34:18 quwen...@cn.fujitsu.com a écrit :
Better check it offline, since online check may not comprehensive than
offline check.
Here you are. Tested from an Ubuntu 13.10 live USB, kernel 3.11 and btrfs-
utils 0.20 - this machine usually runs Arch with kernel 3.13 and
We haven't supported to rebuild extent tree if there are any *FULL BACKREF*
with broken filesystem, disable this option when detecting snapshots.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
cmds-check.c | 62
1 file
xfstests's btrfs/035 triggers a BUG_ON, which we use to detect the split
of inline extents in __btrfs_drop_extents().
For inline extents, we cannot duplicate another EXTENT_DATA item, because
it breaks the rule of inline extents, that is, 'start offset' needs to be 0.
We have set limitations for
Hi Josef,
As i haven't thought any better ideas to rebuild extent tree which contains
extent that owns 'FULL BACKREF' flag.
Considering an extent's refs can be equal or more than 1 if this extent has
*FULL BACKREF* flag, so we could not make sure an extent's flag by only
searching fs/file tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/06/2014 12:55 AM, Miao Xie wrote:
Before applying this patch, the task had to reclaim the metadata
space by itself if the metadata space was not enough. And When the
task started the space reclamation, all the other tasks which
wanted to
On 17 February 2014 09:13, Sachin Kamat sachin.ka...@linaro.org wrote:
PTR_RET is deprecated. Use PTR_ERR_OR_ZERO instead. While at it
also include missing err.h header.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
fs/btrfs/root-tree.c |3 ++-
1 file changed, 2
This is a preparation work, rename waiting_dir_move to send_dir_node.
We'd like to share waiting_dir_move structure in new did_create_dir() code.
Signed-off-by: Liu Bo bo.li@oracle.com
---
v4: Rebase onto the latest btrfs-next.
v3: Nothing.
v2: Fix wrong patch name.
fs/btrfs/send.c | 26
Currently to check whether a directory has been created, we search
DIR_INDEX items one by one to check if children has been processed.
Try to picture such a scenario:
.
|-- dir(ino X)
|-- foo_1(ino X+1)
|-- ...
|-- foo_k(ino X+k)
With the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2014 11:25 AM, Sachin Kamat wrote:
On 17 February 2014 09:13, Sachin Kamat sachin.ka...@linaro.org
wrote:
PTR_RET is deprecated. Use PTR_ERR_OR_ZERO instead. While at it
also include missing err.h header.
Signed-off-by: Sachin Kamat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2014 08:12 AM, Shilong Wang wrote:
Hi Josef,
As i haven't thought any better ideas to rebuild extent tree which
contains extent that owns 'FULL BACKREF' flag.
Considering an extent's refs can be equal or more than 1 if this
extent
On 10 March 2014 21:21, Josef Bacik jba...@fb.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2014 11:25 AM, Sachin Kamat wrote:
On 17 February 2014 09:13, Sachin Kamat sachin.ka...@linaro.org
wrote:
PTR_RET is deprecated. Use PTR_ERR_OR_ZERO instead. While at it
also
On 03/07/2014 07:26 PM, Lennart Poettering wrote:
Heya!
Since yesterday systemd in git can now discover root, /home, /srv and
swap partitions automatically based on GPT type GUIDs, thus making
/etc/fstab unnecessary for simple setups.
I have now put together something like a spec
On Mon, Mar 10, 2014 at 7:34 PM, Goffredo Baroncelli kreij...@libero.it wrote:
On 03/07/2014 07:26 PM, Lennart Poettering wrote:
Since yesterday systemd in git can now discover root, /home, /srv and
swap partitions automatically based on GPT type GUIDs, thus making
/etc/fstab unnecessary for
Hi Kay
On 03/10/2014 07:53 PM, Kay Sievers wrote:
[...]
Instead of relying on the subvolume UUID, why not relying to the subvolume
name: it would be more simple and flexible to manage them.
As a general rule: human-readable names should be left to the
administrator, provide an identifier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/2014 11:44 PM, Wang Shilong wrote:
Test flow is to run fsstress after triggering quota rescan. the
ruler is simple, we just remove all files and directories, sync
filesystem and see if qgroup's ref and excl are nodesize.
Signed-off-by:
On Mar 10, 2014, at 12:34 PM, Goffredo Baroncelli kreij...@libero.it wrote:
On 03/07/2014 07:26 PM, Lennart Poettering wrote:
Heya!
Since yesterday systemd in git can now discover root, /home, /srv and
swap partitions automatically based on GPT type GUIDs, thus making
/etc/fstab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/2014 11:44 PM, Wang Shilong wrote:
Add missing test for btrfs quota groups feature,test idea is to
create a parent qgroup that groups some subvolume groups, we try to
write some data into every subvolume and then check if we exceed
parent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/2014 11:44 PM, Wang Shilong wrote:
So this is a stress test for btrfs quota operations. it can also
detect the following commit fixed problem:
4082bd3d73(Btrfs: fix oops when writting dirty qgroups to disk)
Signed-off-by: Wang
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/24/2014 06:55 AM, Filipe David Borba Manana wrote:
Regression test for a btrfs incremental send issue where invalid
paths for utimes, chown and chmod operations were sent to the send
stream, causing btrfs receive to fail.
If a directory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/25/2014 07:44 PM, Filipe David Borba Manana wrote:
This is a regression test to verify that the restore feature of
btrfs-progs is able to correctly recover files that have compressed
extents, specially when the respective file extent items
On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote:
Heya,
Instead of relying on the subvolume UUID, why not relying to the subvolume
name: it would be more simple and flexible to manage them.
For example supposing to use '@' as prefix for a subvolume name:
@ -
On 03/10/2014 04:02 PM, Lennart Poettering wrote:
On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote:
Heya,
Instead of relying on the subvolume UUID, why not relying to the subvolume
name: it would be more simple and flexible to manage them.
For example supposing to use
On Mar 10, 2014, at 2:21 PM, Chris Mason c...@fb.com wrote:
On 03/10/2014 04:02 PM, Lennart Poettering wrote:
On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote:
Heya,
Instead of relying on the subvolume UUID, why not relying to the subvolume
name: it would be more
On Mon, 10.03.14 14:53, Chris Murphy (li...@colorremedies.com) wrote:
Since it's not a given whether a parent or child subvolume is the one
being updated, it's ambiguous which one to use/automount if there is
inheritance of the proposed subvolumetypeGUID at snapshot
time. Inheritance of the
On 03/10/2014 09:02 PM, Lennart Poettering wrote:
On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote:
Heya,
Instead of relying on the subvolume UUID, why not relying to the subvolume
name: it would be more simple and flexible to manage them.
For example supposing to
On 03/10/2014 09:21 PM, Chris Mason wrote:
On 03/10/2014 04:02 PM, Lennart Poettering wrote:
On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote:
[...]
I am pretty sure automatic discovery of mount points should not cover
the usecase where people install multiple
On Fri, Mar 07, 2014 at 03:41:46PM -0800, Guangyu Sun wrote:
The error message is confusing:
# btrfs sub delete /mnt/mysub/
Delete subvolume '/mnt/mysub'
ERROR: cannot delete '/mnt/mysub' - Directory not empty
The error message does not make sense to me: It's not about deleting a
Hi There
There seems to be an issue if we try to build a btrfs based FS that is
less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)'
failed.
I tried to do a search on this and did not find anything obvious.
On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreij...@libero.it) wrote:
Well, the name is property of the admin really. There needs to be a way
how the admin can label his subvolumes, with a potentially localized
name. This makes it unsuitable for our purpose, we cannot just take
Lennart Poettering wrote:
On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreij...@libero.it) wrote:
Well, the name is property of the admin really. There needs to be a way
how the admin can label his subvolumes, with a potentially localized
name. This makes it unsuitable for our purpose,
Have you tried the -M option to mkfs.btrfs? I'm not sure if we select
it automatically (or if we do, whether you have recent enough tools to
have that).
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo
I'd like to begin testing BTRFS. We'd probably begin roll out in 6
months to a year if testing goes well.
We're currently using CentOS6/64 everywhere, are aware of BTRFS being a
Technology preview in RHEL 7beta and would like to begin testing
production-level load testing. We generate about
On 11 Mar 2014, at 11:39 am, Lists li...@benjamindsmith.com wrote:
Is there a recommended way to do this? Is it anywhere as easy as ZFSonLinux
yum install?
Oracle Linux 6 with the Unbreakable Enterprise Kernel Release 2 or Release 3
has production-ready btrfs support. You can even convert
On 03/11/2014 03:43 AM, Josef Bacik wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/09/2014 11:44 PM, Wang Shilong wrote:
Test flow is to run fsstress after triggering quota rescan. the
ruler is simple, we just remove all files and directories, sync
filesystem and see if qgroup's
On 03/10/2014 11:50 PM, Josef Bacik wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2014 08:12 AM, Shilong Wang wrote:
Hi Josef,
As i haven't thought any better ideas to rebuild extent tree which
contains extent that owns 'FULL BACKREF' flag.
Considering an extent's refs can be
So this is a stress test for btrfs quota operations. it can also
detect the following commit fixed problem:
4082bd3d73(Btrfs: fix oops when writting dirty qgroups to disk)
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
v2-v3:
wait background thread finished before
On Mon, 2014-03-10 at 16:25 -0700, Saul Wold wrote:
Hi There
There seems to be an issue if we try to build a btrfs based FS that is
less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)'
failed.
I tried to do a
On 03/10/2014 07:38 PM, Gui Hecheng wrote:
On Mon, 2014-03-10 at 16:25 -0700, Saul Wold wrote:
Hi There
There seems to be an issue if we try to build a btrfs based FS that is
less than 70M, we get the following assertion failure:
mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion
On Mon, 2014-03-10 at 20:16 -0700, Saul Wold wrote:
On 03/10/2014 07:38 PM, Gui Hecheng wrote:
On Mon, 2014-03-10 at 16:25 -0700, Saul Wold wrote:
Hi There
There seems to be an issue if we try to build a btrfs based FS that is
less than 70M, we get the following assertion failure:
41 matches
Mail list logo
