On Fri, Aug 21, 2015 at 08:30:06AM +0800, Qu Wenruo wrote:
> Hi Mark,
>
> Any further comment on the reason why we should mark all
> nodes/leaves dirty during a subvolume deletion?
No, I see what you're talking about so we'll just ahve to mark all nodes on
the way down the tree, not really a huge
Hello Hugo,
It shouldn't happen, as I understand how the process works. Can you
show the output of "btrfs fi df /mnt/__Complete_Disk"? Let's just
check that everything is indeed RAID-5 still.
Here we go:
btrfs fi df /mnt/__Complete_Disk
Data, RAID5: total=3.79TiB, used=3.78TiB
System, RA
Hi Duncan,
tnx for info. You are quite right about my intentions: do automatic
balance if IO load would be short, notify admin otherwise).
I see the values, but they are quite cryptic without looking at source
code. It seems that free space goes up to 16383, am I right?
I presumed so, and went t
I just want to let you guys know that there are people
waiting for the final patches of the discard problem :)
--
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-
Hello,
For those who have received this message twice already, I sincerely apologize.
Yesterday I filed an issue in the CentOS bug tracker (#9297[1]) and
the Red Hat Bugzilla (#1255512[2]) about OverlayFS with Btrfs as the
upper layer.
The issue was discovered by a colleague of mine, and we veri
Please send your patches to the mailing list for reviews by everybody.
On 8/21/2015 4:18 AM, Qu Wenruo wrote:
Hi Chris,
Would you please consider merging the following fixes for your
integration-4.3 branch?
https://github.com/adam900710/linux.git for_chris_4.3_part1_cleanup
Most of them are
Bostjan Skufca posted on Fri, 21 Aug 2015 17:49:01 +0200 as excerpted:
> is there a way to get information about how much space is occupied in
> each chunk?
>
> In the end, a simple ascii chart of usage distribution should be
> preferable, but I can work towards that if there is a way to get
> in
On Fri, Aug 21, 2015 at 10:45:24AM +1000, Stephen Rothwell wrote:
> Hi Chris,
>
> On Thu, 20 Aug 2015 13:39:18 -0400 Chris Mason wrote:
> >
> > There are a few conflicts for btrfs in linux-next this time. They are
> > small, but I pushed out the merge commit I'm using here:
> >
> > git://git.ke
Swâmi Petaramesh posted on Fri, 21 Aug 2015 17:39:49 +0200 as excerpted:
> Even though I have backups, I don't have too much time and desire for
> breaking and restoring my system, and I'd rather keep this "dead"
> directory forever rather than taking any risk of frying my root FS...
Understood.
Hi all,
is there a way to get information about how much space is occupied in
each chunk?
In the end, a simple ascii chart of usage distribution should be
preferable, but I can work towards that if there is a way to get
information about individual chunks.
I know that "btrfs fi show" displays ag
Hi list,
Thank you all for your replies and suggestions, please see below.
Le vendredi 21 août 2015 11:23:19 Duncan a écrit :
> AFAIK, the bug is now fixed, but for those affected, the bad-refcounts
> remain. I believe btrfs check should detect the problem and with
> --repair should fix it, but
On Fri, Aug 21, 2015 at 10:45:24AM +1000, Stephen Rothwell wrote:
> Hi Chris,
>
> On Thu, 20 Aug 2015 13:39:18 -0400 Chris Mason wrote:
> >
> > There are a few conflicts for btrfs in linux-next this time. They are
> > small, but I pushed out the merge commit I'm using here:
> >
> > git://git.ke
rec->crossing_stripes is not initialized in allocate place,
and have possibility causing wrong report for normal tree block.
Signed-off-by: Zhao Lei
---
cmds-check.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmds-check.c b/cmds-check.c
index 4f18e45..2e6dc68 100644
--- a/cmds-check.c
+
Swâmi Petaramesh posted on Fri, 21 Aug 2015 10:19:54 +0200 as excerpted:
> BTRFS refuses to remove an empty dir and pretends it is not empty (and
> there is no BTRFS subvolume involved in there...)
>
> # uname -r 4.1.5-1-ARCH
[The below description of the bug apparently involved is my not
neces
MASAKI Yuhsuke posted on Fri, 21 Aug 2015 02:11:46 +0900 as excerpted:
> I want to "soft" mirroring between two remote btrfs volumes.
> I tried to use btrfs send/receive [but] it failed everytime.
>
> 1st ) Pipe with SSH, to fresh filesystem. sender was flozen after
> transfared 2.79TiB.
> 2nd )
On Fri, Aug 21, 2015 at 10:19:54AM +0200, Swâmi Petaramesh wrote:
> Hello,
>
> BTRFS refuses to remove an empty dir and pretends it is not empty (and there
> is no BTRFS subvolume involved in there...)
>
> # uname -r
> 4.1.5-1-ARCH
>
>
> # ls -alnR .dropbox-old/
> .dropbox-old/:
> total 0
> dr
Reviewed-by: Zhao Lei
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org
> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Byongho Lee
> Sent: Friday, August 21, 2015 4:52 PM
> To: linux-btrfs@vger.kernel.org
> Subject: [PATCH v2] btrfs-progs: fix memory leaks in error
On Fri, 21 Aug 2015 11:15:23 +0200
Swâmi Petaramesh wrote:
> Le vendredi 21 août 2015 10:47:45 Karsten Heymann a écrit :
> >
> > did you check with lsof that no process has an open file descriptor in
> > that directory?
>
> Yes, I even renamed it and rebooted the machine to be double-sure, but
Le vendredi 21 août 2015 10:47:45 Karsten Heymann a écrit :
>
> did you check with lsof that no process has an open file descriptor in
> that directory?
Yes, I even renamed it and rebooted the machine to be double-sure, but to no
avail...
--
Swâmi Petaramesh http://petaramesh.org PGP 9076E32E
This patch includes below fixes in error path:
1. fix memory leaks if realloc() fails
2. add missing call free_history() before return error in scrub_read_file()
Signed-off-by: Byongho Lee
---
changelog:
v2:
Add one more fix for memory leak when realloc() fails by Zhao Lei's comment.
---
btrfs
Hi Swâmi,
did you check with lsof that no process has an open file descriptor in
that directory?
Regards,
Karsten
2015-08-21 10:19 GMT+02:00 Swâmi Petaramesh :
> Hello,
>
> BTRFS refuses to remove an empty dir and pretends it is not empty (and there
> is no BTRFS subvolume involved in there...)
Hello,
BTRFS refuses to remove an empty dir and pretends it is not empty (and there
is no BTRFS subvolume involved in there...)
# uname -r
4.1.5-1-ARCH
# ls -alnR .dropbox-old/
.dropbox-old/:
total 0
drwx-- 1 1000 1000 18 21 août 09:59 .
drwxr-x--- 1 1000 1000 2624 21 août 10:09 ..
drw
22 matches
Mail list logo
