From: Jan-Simon Möller dl...@gmx.de
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
From: Behan Webster beh...@converseincode.com
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc
From: Jan-Simon Möller dl...@gmx.de
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
From: Jan-Simon Möller dl...@gmx.de
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
From: Behan Webster beh...@converseincode.com
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc
From: Jan-Simon Möller dl...@gmx.de
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
From: Vinícius Tinti viniciusti...@gmail.com
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This is the original VLAIS struct.
struct {
struct shash_desc shash;
char ctx[crypto_shash_descsize(tfm)];
} desc;
This patch instead
From: Behan Webster beh...@converseincode.com
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc
From: Jan-Simon Möller dl...@gmx.de
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
From: Behan Webster beh...@converseincode.com
These patches replace the use of Variable Length Arrays In Structs (VLAIS) in
crypto related code with C99 compliant equivalent code. A SHASH_DESC_ON_STACK()
macro is added to hash.h which is then used to replace the use of VLAIS in all
the other
2014-09-15 9:30 GMT+02:00 beh...@converseincode.com:
[...]
+#define SHASH_DESC_ON_STACK(shash, tfm) \
+ char __desc[sizeof(struct shash_desc) + \
+ crypto_shash_descsize(tfm)] CRYPTO_MINALIGN_ATTR; \
+ struct
On 09/15/14 01:06, Michał Mirosław wrote:
2014-09-15 9:30 GMT+02:00 beh...@converseincode.com:
[...]
+#define SHASH_DESC_ON_STACK(shash, tfm) \
+ char __desc[sizeof(struct shash_desc) + \
+ crypto_shash_descsize(tfm)]
Hi,
sorry for late reply.
On Thu, Jul 03, 2014 at 05:36:35PM +0800, Qu Wenruo wrote:
Also fix a bug that btrfs_read_dev_super() only reads sizeof(struct
btrfs_super_block), corrent size should be BTRFS_SUPER_INFO_SIZE.
Actually it's correct to read only sizeof(super_block), the kernel does
it
On Mon, Sep 15, 2014 at 01:36:12PM +0200, David Sterba wrote:
We've got a report of mismatched checksum and bisected to this patch.
...
But then I don't see the point of the patch, the code would just use a
bigger temprary buffer for no apparent reason, the outcom is the same.
Scatch that, the
On Fri, Sep 05, 2014 at 06:20:49PM +0200, David Sterba wrote:
On Fri, Sep 05, 2014 at 08:55:01AM -0700, Zach Brown wrote:
David, let me know if you want me to change anything or resend so you
don't have to pull this out of a reply in a thread.
Thanks, I'm now aware of the patch in the
Hi Johannes,
Can I have you this tested.. ? Thanks.
---
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index e9676a4..1224b61 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -533,7 +533,7 @@ static noinline int device_list_add(const char *path,
* the
Hi together,
When I invoke `btrfsck --init-extent-tree /dev/sda12`, the process runs
for ~30 to 60 minutes with 100 % usage of one CPU core and then fails
with return code 139 without any feedback - an unexperienced user might
expect the program to have succeeded if he_she doesn't check `echo
On 09/14/2014 12:46 AM, Wang Shilong wrote:
Hi Josef,
One problem that has plagued us is that a user will use up all of his space with
data, remove a bunch of that data, and then try to create a bunch of small files
and run out of space. This happens because all the chunks were allocated for
On Mon, Sep 15, 2014 at 12:30 AM, beh...@converseincode.com wrote:
From: Behan Webster beh...@converseincode.com
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the
On 09/15/14 07:21, Linus Torvalds wrote:
On Mon, Sep 15, 2014 at 12:30 AM, beh...@converseincode.com wrote:
From: Behan Webster beh...@converseincode.com
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount
Hi together,
I'm currently encountering another issue with `btrfs rescue
chunk-recover`. After some seconds of maximal I/O activity, the program
is idle for some seconds and then prints
The chunks in memory can not match the metadata of the fs. Repair
failed.
Fail to recover the
The size unit format is a longstanding annoyance. This patch is based on
the work of Nils and Alexandre and enhances the options. It's possible
to select raw bytes, SI-based or IEC-based compact units (human
frientdly) or a fixed base from kilobytes to terabytes. The default is
compact human
Hi!
I'm having an issue with the 3.17rc5 kernel which prevents having
multiple subvolumes of the same disk mounted.
I'm not sure exactly the cause. I thought it might be because in my
system the root file system is itself a subvolume of the disk I'm trying
to mount. But if I create a second
I should have plenty of space for this operation, but it fails
cartman {~} root# btrfs filesystem df /
Data, RAID1: total=7.59GiB, used=7.00GiB
System, RAID1: total=32.00MiB, used=4.00KiB
Metadata, RAID1: total=1.00GiB, used=438.45MiB
unknown, single: total=148.00MiB, used=0.00
Filesystem
On 09/15/2014 11:13 AM, Sam Thursfield wrote:
Hi!
I'm having an issue with the 3.17rc5 kernel which prevents having
multiple subvolumes of the same disk mounted.
I'm not sure exactly the cause. I thought it might be because in my
system the root file system is itself a subvolume of the
The value of sector for space cache was hardcoded to 4k, and used to
calculate bitmap sizes. In kernel, the BITS_PER_BITMAP is derived from
PAGE_CACHE_SIZE which is not available for userspace, that can also deal
with filesystem of varying sectorsize.
Signed-off-by: David Sterba dste...@suse.cz
Sam,
Thanks for reporting. Can you apply the following diff
on top of 3.17rc5 and check if it helps.
---
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index e9676a4..1224b61 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -533,7 +533,7 @@ static noinline int
On Fri, Sep 05, 2014 at 11:51:24PM +0800, Anand Jain wrote:
Here is a test case which says it all..
mkfs.xfs -f $DEV
mkfs.btrfs -f $DEV
mount $DEV $MNT
mount: /dev/vdiskc: more filesystems detected. This should not happen,
use -t type to explicitly specify the filesystem type or
On Mon, Sep 15, 2014 at 05:09:52PM +0200, David Sterba wrote:
The size unit format is a longstanding annoyance. This patch is based on
the work of Nils and Alexandre and enhances the options. It's possible
to select raw bytes, SI-based or IEC-based compact units (human
frientdly) or a fixed
restoring from an incremental backup breaks the parent UUIDs, making it
impossible to continue doing incremental backup.
1) assume you do incremental backup from home to BACKUP:
btrfs subvol snapshot -r /home /home/backup1
btrfs send /home/backup1 | btrfs receive /BACKUP
btrfs subvol snapshot
Logs from Sam, tells the problem clearly. mount is using
/dev/sda, but mount error message and kernel is using /dev/vda.
--
$ mount /dev/sda /home -t btrfs -o subvol=/state/home,defaults,rw,noatime
mount: /dev/vda is already mounted or /home busy
/dev/vda is
On 15/09/14, Mark Murawski wrote:
I should have plenty of space for this operation, but it fails
[...]
This might be useful:
https://btrfs.wiki.kernel.org/index.php/Balance_Filters
Regards,
Leonidas
--
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
On Sun, 14 Sep 2014 00:45:49 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
Johannes Hirte posted on Sat, 13 Sep 2014 23:23:20 +0200 as excerpted:
On Sat, 13 Sep 2014 19:55:25 +0200 Johannes Hirte
johannes.hi...@datenkhaos.de wrote:
On Sat, 13 Sep 2014 13:36:37 +0800 Anand Jain
Hi Anand
On 15/09/14 17:09, Anand Jain wrote:
Sam,
Thanks for reporting. Can you apply the following diff
on top of 3.17rc5 and check if it helps.
The patch fixes the issue, although it took a little tweaking to get it
to apply cleanly.
---
diff --git a/fs/btrfs/volumes.c
On Mon, 15 Sep 2014 20:32:58 +0800
Anand Jain anand.j...@oracle.com wrote:
Hi Johannes,
Can I have you this tested.. ? Thanks.
---
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index e9676a4..1224b61 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -533,7
On 15/09/14 17:42, Anand Jain wrote:
Logs from Sam, tells the problem clearly. mount is using
/dev/sda, but mount error message and kernel is using /dev/vda.
--
$ mount /dev/sda /home -t btrfs -o subvol=/state/home,defaults,rw,noatime
mount: /dev/vda is already mounted
Hi Sam,
Thanks for verifying.
On 16/09/2014 01:13, Sam Thursfield wrote:
Hi Anand
On 15/09/14 17:09, Anand Jain wrote:
Sam,
Thanks for reporting. Can you apply the following diff
on top of 3.17rc5 and check if it helps.
The patch fixes the issue, although it took a little tweaking
btrfs balance start -dusage=86 /
Done, had to relocate 1 out of 13 chunks
cartman {~} root# btrfs fi df /
Data, RAID1: total=7.03GiB, used=7.01GiB
System, RAID1: total=32.00MiB, used=4.00KiB
Metadata, RAID1: total=1.00GiB, used=438.88MiB
unknown, single: total=148.00MiB, used=0.00
What's this
On 16/09/2014 01:14, Johannes Hirte wrote:
On Mon, 15 Sep 2014 20:32:58 +0800
Anand Jain anand.j...@oracle.com wrote:
Hi Johannes,
Can I have you this tested.. ? Thanks.
---
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index e9676a4..1224b61 100644
---
The patch fixes the issue, although it took a little tweaking to get it
to apply cleanly.
Sam,
In the above context, Can you pls share the btrfs fi show output ?
Thanks, Anand
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to
On Sun, Sep 14, 2014 at 05:18:36PM -0700, Marc MERLIN wrote:
I'm still waiting for the next incremental backup to run.
Once it's done, I'll try to run a smaller one under strace so I don't
have a ridiculously long log to give you.
Is there a reasonable way to know if btrfs receive is indeed
On 15/09/2014 06:47, Jeff Mahoney wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/13/14, 3:31 AM, Anand Jain wrote:
Jeff,
Nice patch. However its better if we do this in the btrfs kernel
function btrfs_scan_one_device(). Since the non-canonicalize path
can still sneak through
Please Revert back, your assistance is needed.
---
The Exhibitor at innoTrans, Berlin 2014
Hall : 15.1 / Stand no : 109
http://www.virtualmarket.innotrans.de/?Action=showCompanyid=346242
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
One problem that has plagued us is that a user will use up all of his space with
data, remove a bunch of that data, and then try to create a bunch of small files
and run out of space. This happens because all the chunks were allocated for
data since the metadata requirements were so low. But now
cartman {/etc/rc2.d} root# btrfs fi show /
Label: 'Root' uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
Total devices 2 FS bytes used 7.43GiB
devid1 size 9.31GiB used 8.37GiB path /dev/sdg6
devid3 size 9.31GiB used 8.37GiB path /dev/sdd6
cartman {/etc/rc2.d} root#
This diff on top of 3.17rc5 also fixes the issue on my box (encrypted
/home subvolume)
Xavier
Hi Sam,
Thanks for verifying.
On 16/09/2014 01:13, Sam Thursfield wrote:
Hi Anand
On 15/09/14 17:09, Anand Jain wrote:
Sam,
Thanks for reporting. Can you apply the following diff
on top
On Sep 15, 2014, at 11:37 AM, Mark Murawski markm-li...@intellasoft.net wrote:
btrfs balance start -dusage=86 /
Done, had to relocate 1 out of 13 chunks
cartman {~} root# btrfs fi df /
Data, RAID1: total=7.03GiB, used=7.01GiB
System, RAID1: total=32.00MiB, used=4.00KiB
Metadata, RAID1:
I started up my computer today to an unmountable rootfs.
I was able to get some recovery media that has kernel 3.16.0 and
btrfsprogs 3.16.0.
I cannot get any of the recovery tools to do anything and some segfault.
# mount -o ro,recovery /dev/sda7 /mnt/sda7/
mount: wrong fs type, bad option,
On Tue, 16 Sep 2014 01:39:49 +0800
Anand Jain anand.j...@oracle.com wrote:
On 16/09/2014 01:14, Johannes Hirte wrote:
On Mon, 15 Sep 2014 20:32:58 +0800
Anand Jain anand.j...@oracle.com wrote:
Hi Johannes,
Can I have you this tested.. ? Thanks.
---
diff --git
Chris Murphy posted on Mon, 15 Sep 2014 14:54:57 -0600 as excerpted:
I still get enospc after a balance with a filter, and then a regular
balance:
cartman {~} root# btrfs balance start /
ERROR: error during balancing '/' - No space left on device
Maybe try mount option enospc_debug and
Tony Murray posted on Mon, 15 Sep 2014 21:41:37 + as excerpted:
Pretty much all tools fail similarly. Is there anyway to recover this?
I just spent several days getting this computer set up and would not
like to spend that much time a second time. If I could pull some files
from the
On Sep 15, 2014, at 3:41 PM, Tony Murray murrayt...@gmail.com wrote:
# btrfs restore -v -i /dev/sda7 /mnt/sdb1/
Starting with umounted volume:
btrfs check dev
btrfs-debug-tree -R dev
Chris Murphy
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a
On Sep 15, 2014, at 6:56 PM, Chris Murphy li...@colorremedies.com wrote:
On Sep 15, 2014, at 3:41 PM, Tony Murray murrayt...@gmail.com wrote:
# btrfs restore -v -i /dev/sda7 /mnt/sdb1/
Starting with umounted volume:
btrfs check dev
btrfs-debug-tree -R dev
Oh nevermind I just saw
On Sep 15, 2014, at 6:08 PM, Duncan 1i5t5.dun...@cox.net wrote:
Assuming such a conversion, did you delete the subvolume containing the
original ext* yet, or not? If not, that may be the problem, because that
subvolume must be left intact in ordered to allow rollback to ext* if
desired.
On Mon, 2014-09-15 at 16:59 +0200, Karl-Philipp Richter wrote:
Hi together,
I'm currently encountering another issue with `btrfs rescue
chunk-recover`. After some seconds of maximal I/O activity, the program
is idle for some seconds and then prints
The chunks in memory can not match
On Sep 12, 2014, at 5:39 PM, Chris Murphy li...@colorremedies.com wrote:
Summary: When a btrfs subvolume is mounted with -o subvol, and a nested ro
subvol/snapshot is created, btrfs send returns with an error. If the top
level (id 5) is mounted instead, the send command succeeds.
I'm not
I wish i could follow your procedure, but this wasn't an ext conversion.
I made this with mkfs for btrfs with kernel circa 3.8ish
On 09/15/14 20:08, Duncan wrote:
Chris Murphy posted on Mon, 15 Sep 2014 14:54:57 -0600 as excerpted:
I still get enospc after a balance with a filter, and then
On 3.14.18 with a BTRFS partition mounted
noatime,autodefrag,compress=lzo, I see the second assertion in
btrfs_set_item_key_safe() trip:
void btrfs_set_item_key_safe(struct btrfs_root *root, struct btrfs_path *path,
struct btrfs_key *new_key)
{
struct
Original Message
Subject: Re: [PATCH v2 1/4] btrfs-progs: Check superblock's checsum when
read dev super
From: David Sterba dste...@suse.cz
To: dste...@suse.cz, Qu Wenruo quwen...@cn.fujitsu.com,
linux-btrfs@vger.kernel.org
Date: 2014年09月15日 19:44
On Mon, Sep 15, 2014 at
Hi Filipe,
# I added Chris to the CC list since this topic is to discuss
# whether the current behavior is correct or not.
(2014/09/11 18:48), Filipe David Manana wrote:
On Thu, Sep 11, 2014 at 5:41 AM, Satoru Takeuchi
takeuchi_sat...@jp.fujitsu.com wrote:
Hi Filipe,
(2014/09/11 0:10),
60 matches
Mail list logo
