insert_inline_extent() checked for compressed_pages to be NULL then
it accessed it under compress_type != BTRFS_COMPRESS_NONE.
This patch adds a BUG() when compress_size != 0, compress_type !=
BTRFS_COMPRESS_NONE and compressed_pages == 0.
Signed-off-by: Fabian Frederick
---
fs/btrfs/inode.c | 8
Duncan posted on Sat, 25 Apr 2015 00:42:12 + as excerpted:
> Also note that if you run smartctl -A (attributes) on the device before
> attempting anything else and check the raw value for ID 5 (reallocated
> sector count), then check again after doing something like that
> badblocks -w, you ca
None None posted on Sat, 25 Apr 2015 05:56:50 +0200 as excerpted:
> Omar Sandoval írta:
>>On Sat, Apr 25, 2015 at 04:47:31AM +0200, None None wrote:
>>> I tried to convert my btrfs from raid1 to raid5 but after the balance
>>> command it's still raid1.
>>
>>This is a known bug in v4.0. I sent in
On Sat, Apr 25, 2015 at 08:18:30AM +, Duncan wrote:
> None None posted on Sat, 25 Apr 2015 05:56:50 +0200 as excerpted:
>
> > Omar Sandoval írta:
> >>On Sat, Apr 25, 2015 at 04:47:31AM +0200, None None wrote:
> >>> I tried to convert my btrfs from raid1 to raid5 but after the balance
> >>> co
My system is openSUSE 13.2, using kernel 3.16.7-21-desktop. I recently
had to reinstall the system, since when /home has become readonly. /home
is a btrfs raid1 array, mirroring both data and metadata.
btrfs check run on unmounted /home gives line after line of parent
transid verification fail
On 25/04/15 11:26, Bob Williams wrote:
My system is openSUSE 13.2, using kernel 3.16.7-21-desktop. I recently
had to reinstall the system, since when /home has become readonly. /home
is a btrfs raid1 array, mirroring both data and metadata.
btrfs check run on unmounted /home gives line after lin
While running xfstests I ran into the following:
[20892.242791] [ cut here ]
[20892.243776] WARNING: CPU: 0 PID: 13299 at fs/btrfs/super.c:260
__btrfs_abort_transaction+0x52/0x114 [btrfs]()
[20892.245874] BTRFS: Transaction aborted (error -2)
[20892.247329] Modules linked
While starting the writes of the dirty block group caches, if we don't
find a block group item in the extent tree we were leaving without
releasing our path, running delayed references and then looping again to
process any new dirty block groups. However this second iteration of the
loop could caus
On Fri, Apr 24, 2015 at 4:05 PM, Filipe David Manana wrote:
> On Fri, Apr 24, 2015 at 2:55 PM, Chris Mason wrote:
>> On 04/24/2015 09:43 AM, Filipe David Manana wrote:
>>> On Fri, Apr 24, 2015 at 2:00 PM, Chris Mason wrote:
>>
Can you please bang on this and get a more reliable reproduction
Hi Duncan,
>> Beyond this corrupted file, is my disk dead?
>> Can I repair the file system or re-create a new one on the same disk?
> A direct answer is beyond my knowledge level, certainly without SMART
> status information, etc.
I attach the result of `smartctl -x` below.
Best regards,
--Marti
At this point I I'm done - after writing the symlink patch I restored
everything of importance off my array to a scratch disk, wiped the
array and am in the process of copying everything back. I'll keep an
eye on this thread if changes need to be made to my patches, but
hopefully I won't be needin
It's a good question. If path_name is absolute, the file descriptor
is ignored. I used -1 (EBADF) instead of AT_FDCWD there so if a
non-absolute path gets in there it errors out instead of attempting to
use a relative path off the current directory.
I'm not entirely sure if it's the best way, s
See also https://bugzilla.kernel.org/show_bug.cgi?id=97271
The attached btrfs-image causes "btrfs check" to write outside of
allocated memory locations and ultimately die due to a segfault. An
adjacent heap block's control structure is overwritten with a `struct
extent_buffer *`, which is not cont
13 matches
Mail list logo
