The commit f495a2ac6611 ("btrfs-progs: fsck: remove unfriendly BUG_ON()
for searching tree failure") is causing tons of extent buffer leak if some
csum mismatches in btrfsck.
This is caused by a misplaced btrfs_release_path(), fix it.
Signed-off-by: Qu Wenruo
---
cmds-check.c | 2 +-
1 file cha
(For commenting, not for integration yet).
We don't check if all devices that passed through the
mount -o device option are indeed belongs to the same fsid.
For which following mount which should fail is successful as of now.
mkfs.btrfs -f /dev/sda
mkfs.btrfs -f /dev/sdb
mount -o device=/dev/sda
On Sun, Jan 4, 2015 at 9:18 PM, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 01/03/2015 12:31 AM, Chris Murphy wrote:
>> This is architecture astronaut territory.
>>
>> The system only has a terrible response for two reasons: 1. The
>> user spec'd the wrong hardw
The commit 1bad43fbe002 ("btrfs-progs: refine btrfs-debug-tree error
prompt when a mount point given")
add judgement on btrfs-debug-tree to restrict only block device to be
executed on, but the command can also be used on regular file, so add
regular file support for the judgement.
Signed-off-by:
Currently, for pre_alloc or delay_alloc, the bytes will be accounted
in space_info by the three guys.
space_info->bytes_may_use --- space_info->reserved --- space_info->used.
But on the other hand, in qgroup, there are only two counters to account the
bytes, qgroup->reserved and qgroup->excl. And q
Hi Josef and others,
This patch set is about enhancing qgroup.
[1/3]: fix a bug about qgroup leak when we exceed quota limit,
It is reviewd by Josef.
[2/3]: introduce a new accounter in qgroup to close a window where
user will exceed the limit by qgroup. It "looks good" to Josef.
Currenly, in data writing, ->reserved is accounted in
fill_delalloc(), but ->may_use is released in clear_bit_hook()
which is called by btrfs_finish_ordered_io(). That's too late,
that said, between fill_delalloc() and btrfs_finish_ordered_io(),
the data is doublely accounted by qgroup. It will cau
When we exceed quota limit in writing, we will free
some reserved extent when we need to drop but not free
account in qgroup. It means, each time we exceed quota
in writing, there will be some remain space in qg->reserved
we can not use any more. If things go on like this, the
all space will be ate
On 01/05/2015 11:25 AM, Eryu Guan wrote:
On Fri, Jan 02, 2015 at 09:04:29PM +0800, Anand Jain wrote:
The subvol delete output has changed with btrfs-progs
Better to point out that since which btrfs-progs version the output
changed.
The fix here is output string change neutral, so it does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/03/2015 12:31 AM, Chris Murphy wrote:
> It's not a made to order hard drive industry. Maybe one day you'll
> be able to 3D print your own with its own specs.
And wookies did not live on endor. What's your point?
> Sticking fingers in your ea
On Fri, Jan 02, 2015 at 09:04:29PM +0800, Anand Jain wrote:
> The subvol delete output has changed with btrfs-progs
Better to point out that since which btrfs-progs version the output
changed.
> -Delete subvolume 'SCRATCH_MNT/snap'
> +Delete subvolume (no-commit): 'SCRATCH_MNT/snap'
>
>
On Fri, 2015-01-02 at 17:21 +0100, David Sterba wrote:
> On Fri, Jan 02, 2015 at 05:12:04PM +0100, David Sterba wrote:
> > On Thu, Jan 01, 2015 at 08:27:55PM -0700, Chris Murphy wrote:
> > > Small problem with the rendering of this commit
> > > d4ef1a06f8be623ae94e4d498c306e8dd1605bef, when I use '
Hi Petr,
On 2014/12/28 0:36, Petr Janecek wrote:
Hello Satoru and all,
that Oct. report was the only time I've experienced the error, so I
don't have much to add. I can try to answer your questions:
Here are my questions.
1. Is your system "btrfs scrub" clean?
yes,
2. Is this messa
On Sun, Jan 4, 2015 at 7:50 AM, Dyweni - BTRFS wrote:
> Hi All,
>
> Just wondering of a few things:
>
> 1. Has anyone seen a problem like this before (see below)? This occurs when
> mounting the file system. It mounts, but goes straight to read-only mode.
> 2. I've scanned the device (/dev/sdd)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/02/2015 04:08 PM, David Sterba wrote:
> On Fri, Jan 02, 2015 at 03:54:55PM -0800, Roger Binns wrote:
>> I can't start a scrub because it is running, and can't cancel it
>> because it isn't running! How do I get out of this state? OS
>> is Ubun
On Sun, Jan 4, 2015 at 8:18 AM, Marc MERLIN wrote:
> badblocks are a thing of the past, as you hinted drives automatically
> remap badblocks so that the filesystem doesn't have to deal with them.
>
> If you have a questionable drive, you can indeed simply dd 0's over it
> before you use it with b
Happy holiday everyone,
TL;DR: Hardware corruption is really bad, if btrfs-restore work,
kernel Btrfs can!
I'm cross-posting this message since the root cause for this problem
is the Ceph RBD device however, my main concern is data loss from a
BTRFS filesystem hosted on this device.
I'm running
Am Sonntag, 4. Januar 2015, 12:40:59 schrieb Erkki Seppala:
> Lutz Vieweg writes:
>
> > Maybe "chattr +C" could print a warning if a file
> > to change attributes for is > 0 bytes long?
>
> This may only affect btrfs. The old ext2? ext3? compression patches
> were able to compress pre-existing f
On Sun, Jan 04, 2015 at 01:45:41AM -0700, Chris Murphy wrote:
> On Sat, Jan 3, 2015 at 10:40 PM, Dyweni - BTRFS
> wrote:
> > Hi All,
> >
> > Can BTRFS ignore bad blocks as they are discovered?
> >
> > I want to try BTRFS on some older drives, but they all have a few bad
> > blocks.
>
> Not curre
Hi All,
Just wondering of a few things:
1. Has anyone seen a problem like this before (see below)? This occurs
when mounting the file system. It mounts, but goes straight to
read-only mode.
2. I've scanned the device (/dev/sdd) using 'badblocks -s v', which
reports no bad blocks found.
3. W
On Sat, Jan 3, 2015 at 10:29 PM, Khaled Ahmed wrote:
> Hi Yang,
>
> This is how to reproduce the bug,
>
> [root@algodev ~]# uname -r
> 3.18.0+
>
> [root@algodev ~]# btrfs version
> Btrfs v3.18-2-g6938452-dirty
>
> [root@algodev ~]# btrfs quota enable LOOP/
> [root@algodev ~]# btrfs qgroup show LO
Lutz Vieweg writes:
> Maybe "chattr +C" could print a warning if a file
> to change attributes for is > 0 bytes long?
This may only affect btrfs. The old ext2? ext3? compression patches
were able to compress pre-existing files. I don't know how other
filesystems behave in this regard.
--
___
lu...@plaintext.sk writes:
Hello,
> luvar@blackdawn:~$ sudo time btrfs balance start -dconvert=raid1 -dusage=20
> /home/luvar/programs/
> Am I doing something forbidden (I have not see any structure where
> raid type is stored per file/subvolume item), or I just hit some
> problem? What should
On Sat, Jan 3, 2015 at 10:40 PM, Dyweni - BTRFS wrote:
> Hi All,
>
> Can BTRFS ignore bad blocks as they are discovered?
>
> I want to try BTRFS on some older drives, but they all have a few bad
> blocks.
Not currently, and I don't see it in the project ideas list. Right now
on Btrfs you will jus
24 matches
Mail list logo
