Nicholas D Steeves posted on Fri, 05 Feb 2016 15:27:55 -0500 as excerpted:
> Hello,
>
> Is it safe to use btrfs-progs-4.4 with linux-3.16.7 patched with the
> following:
>
> linux-3.16.7 Btrfs: fix truncation of compressed and inlined extents
> https://git.kernel.org/linus/0305cd5f7fca85dae392b9
Hello,
Is it safe to use btrfs-progs-4.4 with linux-3.16.7 patched with the
following:
linux-3.16.7
Btrfs: fix truncation of compressed and inlined extents
https://git.kernel.org/linus/0305cd5f7fca85dae392b9ba85b116896eb7c1c7
The specific case I'm looking into is when a Debian user sticks wit
Hello,
I've tried checking around on google but can't find information
regarding the RAM requirements of BTRFS and most of the topics on
stability seem quite old.
So first would be memory requirements, my goal is to use deduplication
and compression. Approximately how many GB of RAM per TB of sto
On Fri, Feb 05, 2016 at 05:07:34PM +0900, Satoru Takeuchi wrote:
> Although BTRFS_ARG_BLKDEV can be returned from check_arg_type(),
> it's not explained the meaning.
>
> Signed-off-by: Satoru Takeuchi
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
t
On 2016-02-04 15:40, Moviuro wrote:
On Thu, Feb 4, 2016 at 9:28 PM Austin S. Hemmelgarn
wrote:
On 2016-02-04 14:40, Chris Murphy wrote:
On Thu, Feb 4, 2016 at 5:53 AM, Austin S. Hemmelgarn
wrote:
4) Possibly get rid of the message on subvolume delete (It provides no
useful information at
On 2016-02-04 22:11, Anand Jain wrote:
If you look critically we have been using UI/CLI as API,
IMO these two class of interfaces be distinct clearly.
Btrfs needs library functions/APIs which is callable in
popular scripting language like python.
I wholeheartedly agree. At a minimum,
The kernel tester found a dereferencing NULL pointer issue with this patch.
I think this is the fix:
--- a/fs/btrfs/root-tree.c
+++ b/fs/btrfs/root-tree.c
@@ -488,7 +488,7 @@ void btrfs_update_root_times(struct
btrfs_trans_handle *trans,
struct btrfs_root *root)
{
From: Filipe Manana
While doing some tests I ran into an hang on an extent buffer's rwlock
that produced the following trace:
[39389.800012] NMI watchdog: BUG: soft lockup - CPU#15 stuck for 22s!
[fdm-stress:32166]
[39389.800016] NMI watchdog: BUG: soft lockup - CPU#14 stuck for 22s!
[fdm-stre
Although BTRFS_ARG_BLKDEV can be returned from check_arg_type(),
it's not explained the meaning.
Signed-off-by: Satoru Takeuchi
---
utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/utils.c b/utils.c
index 3df8b42..eabc36d 100644
--- a/utils.c
+++ b/utils.c
@@ -1007,6 +1007,7 @@ static
