Hi Qu,
> Hi Chris,
>
> Please pull the 19 patchset from my branch for_chris_4.2.
> We have tested it in a week.
>
> Although it is originally based on 4.1-rc5, not the integration branch.
> Quick tests shows no new bugs, although we will rerun the full test,
> I'll send the patchset first for yo
max_to_defrag represents the number of pages to defrag rather than the last
page of the file range to be defragged.
Consider a file having 10 4k blocks (i.e. blocks in the range [0 - 9]). If the
defrag ioctl was invoked for the block range [3 - 6], then max_to_defrag
should actually have the value
On Sat, Jun 06, 2015 at 11:28:43PM +0200, Gabri Mate wrote:
> Dear List,
>
> I have a 12 disk RAID10 btrfs array running on 3.18.14. The FS is 50% and has
> about 100 snapshots. The metadata size is about 450 GB. I was doing a
> metadata balance when the system crashed. After that when I try to
On Mon, Jun 08, 2015 at 11:36:25PM +, Holger Hoffstätte wrote:
> On Mon, 08 Jun 2015 15:05:25 -0700, Mark Fasheh wrote:
>
> > The extent-same code rejects requests with an unaligned length. This
> > poses a problem when we want to dedupe the tail extent of files as we
> > skip cloning the port
On Mon, 08 Jun 2015 15:05:25 -0700, Mark Fasheh wrote:
> The extent-same code rejects requests with an unaligned length. This
> poses a problem when we want to dedupe the tail extent of files as we
> skip cloning the portion between i_size and the extent boundary.
This sounds familiar:
http://thr
On Mon, Jun 08, 2015 at 03:05:25PM -0700, Mark Fasheh wrote:
> The extent-same code rejects requests with an unaligned length. This
> poses a problem when we want to dedupe the tail extent of files as we
> skip cloning the portion between i_size and the extent boundary.
>
> If we don't clone the e
The extent-same code rejects requests with an unaligned length. This
poses a problem when we want to dedupe the tail extent of files as we
skip cloning the portion between i_size and the extent boundary.
If we don't clone the entire extent, it won't be deleted. So the
combination of these behavior
Hello!
I have a raid1-btrfs-system (Kernel 3.19.0-18-generic, Ubuntu Vivid Vervet,
btrfs-tools 3.17-1.1). One disk failed some days ago. I could remount the
remaining one with "-o degraded". After one day and some write-operations
(with no errrors) I had to reboot the system. And now I can not
On 06/06/2015 02:07 AM, Tomasz Chmielewski wrote:
> 4.1-rc6, busy filesystem.
>
> I was running mongo import which made quite a lot of IO.
> During the import, I did "chattr +C /var/lib/mongodb" - shortly after I
> saw this in dmesg and server died:
>
> [57860.149839] BUG: unable to handle kernel
On Wed, Jun 3, 2015 at 3:47 PM, wrote:
> From: Jeff Mahoney
>
> When we clear the dirty bits in btrfs_delete_unused_bgs for extents
> in the empty block group, it results in btrfs_finish_extent_commit being
> unable to discard the freed extents.
>
> The block group removal patch added an alterna
On Mon, Jun 8, 2015 at 4:44 AM, Robbie Ko wrote:
> Hi Filipe,
Hi Robbie,
>
> I've fixed "don't send utimes for non-existing directory" with another
> solution.
>
> In apply_dir_move(), the old parent dir. and new parent dir. will be
> updated after the current dir. has moved.
>
> And there's o
Hi
I started a disk replacement around 11:00 with following command:
btrfs replace start /dev/iscsi/diskA /dev/diskB /export/backup
The disks has a size of 10TiB.
Now (15:00)i`ve checked the status and get
btrfs replace status -1 /export/backup/
143.7% done, 0 write err
From: Zhao Lei
It is introduced by:
c404e0dc2c843b154f9a36c3aec10d0a715d88eb
Btrfs: fix use-after-free in the finishing procedure of the device replace
But seems no relationship with that bug, this patch revirt these
code block for cleanup.
Signed-off-by: Zhao Lei
---
fs/btrfs/volumes.c | 2
13 matches
Mail list logo
