Kernel panic occurred due to NULL pointer reference in can_overcommit().
Because btrfs_async_reclaim_metadata_space() passed NULL pointer to
btrfs_calc_reclaim_metadata_size().
[ 3756.152833] BUG: unable to handle kernel NULL pointer der
In the newer kernel, supported kernel features can be known from
/sys/fs/btrfs/features
however this interface was introduced only after 3.14, and most the
incompatible FS features were introduce before 3.14.
This patch proposes to maintain kernel version against the feature list,
and so that wi
btrfs-convert convert FS with latest default features enabled, and
if the kernel is down-rev and does not support a latest feature then
mount fails, as expected.
This patch disables default features based on the running kernel.
Signed-off-by: Anand Jain
---
btrfs-convert.c | 5 -
1 file cha
mkfs from latest btrfs-progs will enable latest default features,
and if the kernel is down-rev and does not support a latest default
feature then mount fails, as expected.
This patch disables default features based on the running kernel.
Signed-off-by: Anand Jain
---
mkfs.c | 5 -
1 file c
This patch have LOT of errors, sorry, please ignore it.
2015-10-21 4:11 GMT+03:00 Timofey Titovets :
> It's just a proof of concept, and i hope to see feedback/ideas/review about
> it.
> ---
> While deduplication,
> Btrfs produce extent and file fragmentation
> But it's can be optimized by compute
Hi Anand,
This feature seems quite good, comment inlined below.
Anand Jain wrote on 2015/10/21 16:45 +0800:
In the newer kernel, supported kernel features can be known from
/sys/fs/btrfs/features
however this interface was introduced only after 3.14, and most the
incompatible FS features wer
Anand Jain wrote on 2015/10/21 16:45 +0800:
btrfs-convert convert FS with latest default features enabled, and
if the kernel is down-rev and does not support a latest feature then
mount fails, as expected.
This patch disables default features based on the running kernel.
Signed-off-by: Anand
Anand Jain wrote on 2015/10/21 16:45 +0800:
mkfs from latest btrfs-progs will enable latest default features,
and if the kernel is down-rev and does not support a latest default
feature then mount fails, as expected.
This patch disables default features based on the running kernel.
Signed-off
On Tue, Oct 20, 2015 at 06:28:00PM +0800, Eryu Guan wrote:
> On Mon, Oct 19, 2015 at 03:41:04PM +0200, David Sterba wrote:
> > On Mon, Oct 19, 2015 at 07:37:52PM +0800, Eryu Guan wrote:
> > > Coverity reports assigning value from "err" to "ret", but that stored
> > > value is overwritten by check_e
On Wed, Oct 21, 2015 at 12:50:06AM +0200, Christian Engelmayer wrote:
> Commit 8eb934591f8b ("btrfs: check unsupported filters in balance
> arguments") adds a jump to exit label out_bargs in case the argument
> check fails. At this point in addition to the bargs memory, the
> memory for struct btrf
On 2015-10-21 00:40, Henk Slager wrote:
> I had a similar issue some time ago, around the time kernel 4.1.6 was
> just there.
> In case you don't want to wait for new disk or decide to just run the
> filesystem with 1 disk less or maybe later on replace 1 of the still
> healthy disks with a double/
On Wed, Oct 21, 2015 at 04:20:00PM +0900, Tsutomu Itoh wrote:
> Kernel panic occurred due to NULL pointer reference in can_overcommit().
> Because btrfs_async_reclaim_metadata_space() passed NULL pointer to
> btrfs_calc_reclaim_metadata_size().
> fs_info->fs_root is referred in btrfs_async_reclaim
On Mon, Oct 19, 2015 at 07:37:55PM +0800, Eryu Guan wrote:
> Coverity reports execution cannot reach this statements. So put WARN_ON
> in if-else conditions.
>
> Signed-off-by: Eryu Guan
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a m
On 2015-10-20 15:59, Austin S Hemmelgarn wrote:
On 2015-10-20 15:20, Duncan wrote:
Yes, there's some small but not infinitesimal chance the checksum may be
wrong, but if there's two copies of the data and the checksum on one is
wrong while the checksum on the other verifies... yes, there's still
On Tue, Oct 20, 2015 at 10:33:37AM +0800, Qu Wenruo wrote:
> Finally, the bug is found.
Great, thanks!
>
> A SUPER AWKWARD TYPO
Happens ... :)
> See the patch just submitted:
> [PATCH] btrfs-progs: Fix a typo which causes super_copy corrupted
>
> And, I think that's also the reason why PPC
On 2015-10-21 07:51, Austin S Hemmelgarn wrote:
On 2015-10-20 15:59, Austin S Hemmelgarn wrote:
On 2015-10-20 15:20, Duncan wrote:
Yes, there's some small but not infinitesimal chance the checksum may be
wrong, but if there's two copies of the data and the checksum on one is
wrong while the che
On Tue, Oct 20, 2015 at 10:20:44AM +0800, Qu Wenruo wrote:
> In btrfs_read_dev_super(), a wrong parameter for memcpy will copy wrong
> address of a stack pointer to super_copy.
> Which will cause a lot of unpredictable error.
>
> What a stupid typo from myself!
>
> Signed-off-by: Qu Wenruo
Thanks for the comments.. more below.
On 10/21/2015 05:12 PM, Qu Wenruo wrote:
Anand Jain wrote on 2015/10/21 16:45 +0800:
mkfs from latest btrfs-progs will enable latest default features,
and if the kernel is down-rev and does not support a latest default
feature then mount fails, as expect
在 2015年10月21日 22:15, Anand Jain 写道:
Thanks for the comments.. more below.
On 10/21/2015 05:12 PM, Qu Wenruo wrote:
Anand Jain wrote on 2015/10/21 16:45 +0800:
mkfs from latest btrfs-progs will enable latest default features,
and if the kernel is down-rev and does not support a latest defa
On 10/21/15 4:09 AM, Qu Wenruo wrote:
>> +static int get_kernel_code()
>> +{
>> +int ret;
>> +struct utsname utsbuf;
>> +char *version;
>> +
>> +ret = uname(&utsbuf);
>> +if (ret)
>> +return -ret;
>> +
>> +version = strtok(utsbuf.release, "-");
>> +
>> +return ve
On 10/21/2015 10:41 PM, Eric Sandeen wrote:
On 10/21/15 4:09 AM, Qu Wenruo wrote:
+static int get_kernel_code()
+{
+int ret;
+struct utsname utsbuf;
+char *version;
+
+ret = uname(&utsbuf);
+if (ret)
+return -ret;
+
+version = strtok(utsbuf.release, "-");
+
+
On Tue, Sep 22, 2015 at 08:02:25PM +, Alexandru Moise wrote:
> Improve readability by generalizing the profile validity checks.
>
> Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
Reviewed-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe linux-btrf
On Mon, Sep 21, 2015 at 11:40:57AM +0800, Shan Hai wrote:
> From: Shan Hai
>
> The commit b37392ea86761 ("Btrfs: cleanup unnecessary parameter
> and variant of prepare_pages()") makes it redundant.
>
> Signed-off-by: Shan Hai
Reviewed-by: David Sterba
--
To unsubscribe from this list: send th
On 10/21/15 9:49 AM, Anand Jain wrote:
>
>
> On 10/21/2015 10:41 PM, Eric Sandeen wrote:
>> On 10/21/15 4:09 AM, Qu Wenruo wrote:
+static int get_kernel_code()
+{
+int ret;
+struct utsname utsbuf;
+char *version;
+
+ret = uname(&utsbuf);
+
On Wed, Oct 21, 2015 at 2:07 PM, Austin S Hemmelgarn
wrote:
> And I realize of course right after sending this that my other reply didn't
> get through because GMail refuses to send mail in plain text, no matter how
> hard I beat it over the head...
In the web browser version, to the right of the
I went through all the recovery options I could find (starting from
read-only to "extraordinarily dangerous"). Nothing seemed to work.
A Windows based proprietary recovery software (ReclaiMe) could scratch
the surface but only that (it showed me the whole original folder
structure after a few minu
On Wed, Oct 21, 2015 at 11:54 AM, Dmitry Katsubo
wrote:
> On 2015-10-21 00:40, Henk Slager wrote:
>> I had a similar issue some time ago, around the time kernel 4.1.6 was
>> just there.
>> In case you don't want to wait for new disk or decide to just run the
>> filesystem with 1 disk less or maybe
If it is for mostly archival storage, I would suggest you take a look
at snapraid.
On Wed, Oct 21, 2015 at 9:09 AM, Janos Toth F. wrote:
> I went through all the recovery options I could find (starting from
> read-only to "extraordinarily dangerous"). Nothing seemed to work.
>
> A Windows based
Hi,
a bunch of cleanup patches from the mailinglist, no functional changes.
Reviewed and compile-tested, merge with current integration is without
conflits. Please pull, thanks.
The following changes since commit 25cb62b76430a91cc61
On Wed, Jul 22, 2015 at 10:45 AM, Davide Italiano wrote:
> On Fri, Jun 26, 2015 at 7:08 AM, David Sterba wrote:
>> On Mon, Apr 06, 2015 at 10:09:15PM -0700, Davide Italiano wrote:
>>> - We call inode_size_ok() only if FL_KEEP_SIZE isn't specified.
>>> - As an optimisation we can skip the call if
On 2015-10-21 12:01, Chris Murphy wrote:
On Wed, Oct 21, 2015 at 2:07 PM, Austin S Hemmelgarn
wrote:
And I realize of course right after sending this that my other reply didn't
get through because GMail refuses to send mail in plain text, no matter how
hard I beat it over the head...
In the w
Maybe hold off erasing the drives a little in case someone wants to
collect some extra data for diagnosing how/why the filesystem got into
this unrecoverable state.
A single device having issues should not cause the whole filesystem to
become unrecoverable.
On Wed, Oct 21, 2015 at 9:09 AM, Janos
On Fri, Aug 7, 2015 at 5:01 AM, Liu Bo wrote:
> Hi,
>
> On Wed, Aug 05, 2015 at 10:28:05AM +0200, Elias Probst wrote:
>> I can reproduce a hard btrfs lockup (process issuing the ioctl() is in
>> D-state, same goes for btrfs-transacti process) on Kernel 4.2.0-rc5.
>>
>> I had the same issue on 4.1,
I tried several things, including the degraded mount option. One example:
# mount /dev/sdb /data -o ro,degraded,nodatasum,notreelog
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
missing codepage or helper program, or other error
In some cases useful info is found in
I am afraid the filesystem right now is really damaged regardless of
it's state upon the unexpected cable failure because I tried some
dangerous options after read-only restore/recovery methods all failed
(including zero-log, followed by init-csum-tree and even
chunk-recovery -> all of them just sp
Hi Henk,
This trick/hack worked great for me. After the rebalance was
complete, a sparse file + loop device, `btrfs replace` and `btrfs
delete` worked as expected. Thanks.
In other news, I did hit a btrfs bug 3 times while attempting to
balance. I've added my comments @
https://bugzilla.kernel
Hi there!
Is it possible, what i've recognized now. My system (debian) runs on
btrfs, and i have a lot of snapshots on my hard-disk.
Since some days my system freezes totally. I recognized, it always
happens during btrfs-balance.
So i deleted some of the old snapshots and tried another balance-ru
https://btrfs.wiki.kernel.org/index.php/Restore
This should still be possible with even a degraded/unmounted raid5. It
is a bit tedious to figure out how to use it but if you've got some
things you want off the volume, it's not so difficult to prevent
trying it.
Chris Murphy
--
To unsubscribe fr
I had a number of similar btrfs balance crashes in the past few days,
but the disk wasn't full. You should try tailing the system logs from
a remote machine when it happens. You'll likely see some bug info
before the system dies and becomes unusable.
The issue I encountered is described @
https:/
Hello David Sterba,
The patch 8eb934591f8b: "btrfs: check unsupported filters in balance
arguments" from Oct 12, 2015, leads to the following static checker
warning:
fs/btrfs/ioctl.c:4673 btrfs_ioctl_balance()
warn: possible memory leak of 'bctl'
fs/btrfs/ioctl.c
4624
Thx!
It seems to be the same bug.
Am 2015-10-21 um 22:51 schrieb Kyle Manna:
> I had a number of similar btrfs balance crashes in the past few days,
> but the disk wasn't full. You should try tailing the system logs from
> a remote machine when it happens. You'll likely see some bug info
> befor
On Wed, Oct 21, 2015 at 11:55:00PM +0300, Dan Carpenter wrote:
> Hello David Sterba,
>
> The patch 8eb934591f8b: "btrfs: check unsupported filters in balance
> arguments" from Oct 12, 2015, leads to the following static checker
> warning:
>
> fs/btrfs/ioctl.c:4673 btrfs_ioctl_balance()
>
Hello, while using linux-4.2.3 (btrfs-progs v4.2.2) with the latest
grsec patch to date, a feature in the grsec patchset, an overflow
checker (made by emese) seems to have found some bugs in the btrfs
code itself (this is not caused by grsec).
First bug: fs/btrfs/inode.c:5759
For example --
On 2015/10/21 20:27, David Sterba wrote:
On Wed, Oct 21, 2015 at 04:20:00PM +0900, Tsutomu Itoh wrote:
Kernel panic occurred due to NULL pointer reference in can_overcommit().
Because btrfs_async_reclaim_metadata_space() passed NULL pointer to
btrfs_calc_reclaim_metadata_size().
fs_info->fs_r
Normal btrfs_item_key_to_cpu() will need extent buffer to do it, and
there is not stack version to handle in memory leaf.
Add btrfs_stack_item_key_to_cpu() function for such operation, which
will provide the basis for later qgroup fix.
Signed-off-by: Qu Wenruo
---
v2:
Change the char* paramete
Ancient qgroup code call memcpy() on a extent buffer and use it for leaf
iteration.
As extent buffer contains lock, pointers to pages, it's never sane to do
such copy.
The following bug may be caused by this insane operation:
[92098.841309] general protection fault: [#1] SMP
[92098.841338] M
On Thu, Oct 22, 2015 at 12:52:37AM +0200, David Sterba wrote:
> On Wed, Oct 21, 2015 at 11:55:00PM +0300, Dan Carpenter wrote:
> > Hello David Sterba,
> >
> > The patch 8eb934591f8b: "btrfs: check unsupported filters in balance
> > arguments" from Oct 12, 2015, leads to the following static checke
I tried that after every possible combinations of RO mount failed. I used it in
the past for an USB attached drive where an USB-SATA adapter had some issues (I
plugged it into a standard USB2 port even though it expected USB3 power
current, so a high-current or several standard USB2 ports should
Hi,
more details about this RFC as below..
So a user with old kernel won't be able to create a filesystem with
newer feature forever.
Thats not true. Here below is an example of the problem and fix
in action.
Maybe the user are just making btrfs for his or her newer kernel?
Yes. Tha
Kyle Manna posted on Wed, 21 Oct 2015 13:51:22 -0700 as excerpted:
> The issue I encountered is described @
> https://bugzilla.kernel.org/show_bug.cgi?id=105681
FWIW...
I won't try to deal with the issue reported there, but I can help clear
something up that's mentioned on the bug[1].
The ques
Noticed that at print_one_uuid() some of the members of btrfs_fs_devices
contained some junk values. It took a while to dig this further, and found
that we make a local copy of the btrfs_fs_devices list at
search_umounted_fs_uuids() and wasn't initialized properly.
Fixed using using zalloc instead
---
utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/utils.c b/utils.c
index f1e3248..b754686 100644
--- a/utils.c
+++ b/utils.c
@@ -763,6 +763,7 @@ int btrfs_add_to_fsid(struct btrfs_trans_handle *trans,
if (!device->name)
goto err_nomem;
+ INIT_LIST_HEA
Anand Jain wrote on 2015/10/22 11:09 +0800:
Hi,
more details about this RFC as below..
So a user with old kernel won't be able to create a filesystem with
newer feature forever.
Thats not true. Here below is an example of the problem and fix
in action.
Maybe the user are just mak
Hello,
Recently I added daily rebalancing to my cron.d (after finding myself in
the no-space-situation), and not long after that, I found my PC had
crashed over night. Having no sign in the logs anywhere (not even over
network even though there should be) I had nothing to go on, but this
night it
54 matches
Mail list logo