On 03/10/2014 10:47 PM, Gui Hecheng wrote:
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 t
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
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 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
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
---
v2->v3:
wait background thread finished before umounting.(Thanks to Josef)
v1->v2:
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
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 ref
On 11 Mar 2014, at 11:39 am, Lists 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 your existing CentOS6
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
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 in
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
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
> > p
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.
Further
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
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 distr
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 su
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 th
On Mar 10, 2014, at 2: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:
>>
>> Heya,
>>
>>> Instead of relying on the subvolume UUID, why not relying to the subvolume
>>> name: it would be mo
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 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:
>
> @
-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
-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 director
-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 S
-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
> par
On Mar 10, 2014, at 12:34 PM, Goffredo Baroncelli 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 unnecessary for s
-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-
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 iden
On Mon, Mar 10, 2014 at 7:34 PM, Goffredo Baroncelli 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 simple setup
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 de
On 10 March 2014 21:21, Josef Bacik 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
>> wrote:
>>> PTR_RET is deprecated. Use PTR_ERR_OR_ZERO instead. While at it
>>> also include missing err.h head
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2014 11:25 AM, Sachin Kamat wrote:
> On 17 February 2014 09:13, Sachin Kamat
> 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 ---
>> fs/btr
-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
> ext
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 curre
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
---
v4: Rebase onto the latest btrfs-next.
v3: Nothing.
v2: Fix wrong patch name.
fs/btrfs/send.c | 26 +---
On 17 February 2014 09:13, Sachin Kamat 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
> ---
> fs/btrfs/root-tree.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrf
-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
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 an
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
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
---
cmds-check.c | 62
1 file changed, 62 insertions(+)
diff
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
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
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 http://petaramesh.org PGP 9076E32E
--
To unsubscri
42 matches
Mail list logo
