Chris Murphy , 29 Ağu 2018 Çar, 02:58
tarihinde şunu yazdı:
>
> On Tue, Aug 28, 2018 at 5:04 PM, Cerem Cem ASLAN
> wrote:
> > What I want to achive is that I want to add the problematic disk as
> > raid1 and see how/when it fails and how BTRFS recovers these fails.
> > While the party goes on, th
"Huang, Ying" writes:
> Josef Bacik writes:
>
>> On Thu, Aug 02, 2018 at 01:55:23PM +0800, Huang, Ying wrote:
>>> "Huang, Ying" writes:
>>>
>>> > Hi, Chris,
>>> >
>>> > Chris Mason writes:
>>> >
>>> >> On 19 Jun 2018, at 23:51, Huang, Ying wrote:
>>> > "Huang, Ying" writes:
>>> >
>>>
On 2018/8/28 下午9:56, Chris Murphy wrote:
> On Tue, Aug 28, 2018 at 7:42 AM, Qu Wenruo wrote:
>>
>>
>> On 2018/8/28 下午9:29, Larkin Lowrey wrote:
>>> On 8/27/2018 10:12 PM, Larkin Lowrey wrote:
On 8/27/2018 12:46 AM, Qu Wenruo wrote:
>
>> The system uses ECC memory and edac-util has n
Gentle ping.
These fixes are pretty small, I'd like to see them merged before I need
to rebase them again and again.
Thanks,
Qu
On 2018/8/3 下午1:50, Qu Wenruo wrote:
> This can be fetched from github:
> https://github.com/adam900710/btrfs-progs/tree/fixes_for_fuzz_test
>
> The base HEAD is:
> co
Function btrfs_trim_fs() doesn't handle errors in a consistent way, if
error happens when trimming existing block groups, it will skip the
remaining blocks and continue to trim unallocated space for each device.
And the return value will only reflect the final error from device
trimming.
This pat
This patchset can be fetched from github:
https://github.com/adam900710/linux/tree/trim_fix
Which is based on v4.19-rc1 tag.
This patchset introduces 2 enhancement, one to output better error
messages during trim, the other one is to ensure we could really trim
block groups if logical bytenr of bl
[BUG]
fstrim on some btrfs only trims the unallocated space, not trimming any
space in existing block groups.
[CAUSE]
Before fstrim_range passed to btrfs_trim_fs(), it get truncated to
range [0, super->total_bytes).
So later btrfs_trim_fs() will only be able to trim block groups in range
[0, super
On 2018/8/28 下午9:56, Chris Murphy wrote:
> On Tue, Aug 28, 2018 at 7:42 AM, Qu Wenruo wrote:
>>
>>
>> On 2018/8/28 下午9:29, Larkin Lowrey wrote:
>>> On 8/27/2018 10:12 PM, Larkin Lowrey wrote:
On 8/27/2018 12:46 AM, Qu Wenruo wrote:
>
>> The system uses ECC memory and edac-util has n
On Tue, Aug 28, 2018 at 1:14 PM, Menion wrote:
> You are correct, indeed in order to cleanup you need
>
> 1) someone realize that snapshots have been created
> 2) apt-brtfs-snapshot is manually installed on the system
>
> Assuming also that the snapshots created during do-release-upgrade are
> man
On Tue, Aug 28, 2018 at 8:56 AM, Menion wrote:
> [sudo] password for menion:
> ID gen top level path
> -- --- -
> 257 600627 5 /@
> 258 600626 5 /@home
> 296 599489 5
> /@apt-snapshot-release-upgrade-bionic-2018-
On Tue, Aug 28, 2018 at 5:04 PM, Cerem Cem ASLAN wrote:
> What I want to achive is that I want to add the problematic disk as
> raid1 and see how/when it fails and how BTRFS recovers these fails.
> While the party goes on, the main system shouldn't be interrupted
> since this is a production syste
What I want to achive is that I want to add the problematic disk as
raid1 and see how/when it fails and how BTRFS recovers these fails.
While the party goes on, the main system shouldn't be interrupted
since this is a production system. For example, I would never expect
to be ended up with such a r
Hello,
I get the following WARNING while de-duplicating with bedup 0.10.1. I am
running Debian with backports kernel:
Linux lithium 4.17.0-0.bpo.1-amd64 #1 SMP Debian 4.17.8-1~bpo9+1
(2018-07-23) x86_64 GNU/Linux
I ran:
sudo bedup scan /media/btrfs/
sudo bedup dedupe /media/btrfs/
/media/btr
On Tue, Aug 28, 2018 at 12:50 PM, Cerem Cem ASLAN wrote:
> I've successfully moved everything to another disk. (The only hard
> part was configuring the kernel parameters, as my root partition was
> on LVM which is on LUKS partition. Here are the notes, if anyone
> needs:
> https://github.com/cer
Hi Filipe,
This is to follow up the status of crash consistency bugs we reported
on btrfs. We see that there has been a patch(not in the kernel yet)
(https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg77875.html)
that resolves one of the reported bugs. However, the other bugs we
reported
On 2018-08-28 15:14, Menion wrote:
You are correct, indeed in order to cleanup you need
1) someone realize that snapshots have been created
2) apt-brtfs-snapshot is manually installed on the system
Your second requirement is only needed if you want the nice automated
cleanup. There's absolutel
I've successfully moved everything to another disk. (The only hard
part was configuring the kernel parameters, as my root partition was
on LVM which is on LUKS partition. Here are the notes, if anyone
needs:
https://github.com/ceremcem/smith-sync/blob/master/create-bootable-backup.md)
Now I'm see
On Tue, Aug 28, 2018 at 1:25 PM Menion wrote:
>
> Ok, I have removed the snapshot and the free expected space is here, thank
> you!
> As a side note: apt-btrfs-snapshot was not installed, but it is
> present in Ubuntu repository and I have used it (and I like the idea
> of automatic snapshot duri
Ok, I have removed the snapshot and the free expected space is here, thank you!
As a side note: apt-btrfs-snapshot was not installed, but it is
present in Ubuntu repository and I have used it (and I like the idea
of automatic snapshot during upgrade)
This means that the do-release-upgrade does it's
On 2018-08-28 12:05, Noah Massey wrote:
On Tue, Aug 28, 2018 at 11:47 AM Austin S. Hemmelgarn
wrote:
On 2018-08-28 11:27, Noah Massey wrote:
On Tue, Aug 28, 2018 at 10:59 AM Menion wrote:
[sudo] password for menion:
ID gen top level path
-- --- -
On Tue, Aug 28, 2018 at 11:47 AM Austin S. Hemmelgarn
wrote:
>
> On 2018-08-28 11:27, Noah Massey wrote:
> > On Tue, Aug 28, 2018 at 10:59 AM Menion wrote:
> >>
> >> [sudo] password for menion:
> >> ID gen top level path
> >> -- --- -
> >> 257 600627
On 2018-08-28 11:27, Noah Massey wrote:
On Tue, Aug 28, 2018 at 10:59 AM Menion wrote:
[sudo] password for menion:
ID gen top level path
-- --- -
257 600627 5 /@
258 600626 5 /@home
296 599489 5
/@apt-snapsho
On Tue, Aug 28, 2018 at 10:59 AM Menion wrote:
>
> [sudo] password for menion:
> ID gen top level path
> -- --- -
> 257 600627 5 /@
> 258 600626 5 /@home
> 296 599489 5
> /@apt-snapshot-release-upgrade-bionic-201
[sudo] password for menion:
ID gen top level path
-- --- -
257 600627 5 /@
258 600626 5 /@home
296 599489 5
/@apt-snapshot-release-upgrade-bionic-2018-08-27_15:29:55
297 599489 5
/@apt-snapshot-release-upgrad
On Tue, Aug 28, 2018 at 7:42 AM, Qu Wenruo wrote:
>
>
> On 2018/8/28 下午9:29, Larkin Lowrey wrote:
>> On 8/27/2018 10:12 PM, Larkin Lowrey wrote:
>>> On 8/27/2018 12:46 AM, Qu Wenruo wrote:
> The system uses ECC memory and edac-util has not reported any errors.
> However, I will run a
On Tue, Aug 28, 2018 at 3:34 AM, Menion wrote:
> Hi all
> I have run a distro upgrade on my Ubuntu 16.04 that runs ppa kernel
> 4.17.2 with btrfsprogs 4.17.0
> The root filesystem is BTRFS single created by the Ubuntu Xenial
> installer (so on kernel 4.4.0) on an internal mmc, located in
> /dev/mm
On 2018/8/28 下午9:29, Larkin Lowrey wrote:
> On 8/27/2018 10:12 PM, Larkin Lowrey wrote:
>> On 8/27/2018 12:46 AM, Qu Wenruo wrote:
>>>
The system uses ECC memory and edac-util has not reported any errors.
However, I will run a memtest anyway.
>>> So it should not be the memory problem.
On 8/27/2018 10:12 PM, Larkin Lowrey wrote:
On 8/27/2018 12:46 AM, Qu Wenruo wrote:
The system uses ECC memory and edac-util has not reported any errors.
However, I will run a memtest anyway.
So it should not be the memory problem.
BTW, what's the current generation of the fs?
# btrfs inspe
On 2018/8/28 下午9:07, Menion wrote:
> Ok, thanks for your replay
> This is a root FS, how can I defragment it?
If it's a rootfs, then it's a little strange.
Normally package manager should overwrite the whole file during package
update transaction, thus the extent booking doesn't happen as frequ
Ok, thanks for your replay
This is a root FS, how can I defragment it?
If I try to launch it I get this output:
menion@Menionubuntu:~$ sudo btrfs filesystem defragment -r /
ERROR: defrag failed on /bin/bash: Text file busy
ERROR: defrag failed on /bin/dash: Text file busy
ERROR: defrag failed on /
On 2018/8/28 下午5:34, Menion wrote:
> Hi all
> I have run a distro upgrade on my Ubuntu 16.04 that runs ppa kernel
> 4.17.2 with btrfsprogs 4.17.0
> The root filesystem is BTRFS single created by the Ubuntu Xenial
> installer (so on kernel 4.4.0) on an internal mmc, located in
> /dev/mmcblk0p3
> A
On 2018/8/28 下午7:48, Nikolay Borisov wrote:
>
>
> On 28.08.2018 14:46, Qu Wenruo wrote:
>>
>>
>> On 2018/8/28 下午4:48, Nikolay Borisov wrote:
>>>
>>>
>>> On 28.08.2018 09:46, Qu Wenruo wrote:
Although we have space_info::bytes_may_use underflow detection in
btrfs_free_reserved_data_sp
On 28.08.2018 14:46, Qu Wenruo wrote:
>
>
> On 2018/8/28 下午4:48, Nikolay Borisov wrote:
>>
>>
>> On 28.08.2018 09:46, Qu Wenruo wrote:
>>> Although we have space_info::bytes_may_use underflow detection in
>>> btrfs_free_reserved_data_space_noquota(), we have more callers who are
>>> subtractin
On 2018/8/28 下午4:48, Nikolay Borisov wrote:
>
>
> On 28.08.2018 09:46, Qu Wenruo wrote:
>> Although we have space_info::bytes_may_use underflow detection in
>> btrfs_free_reserved_data_space_noquota(), we have more callers who are
>> subtracting number from space_info::bytes_may_use.
>>
>> So
On 2018-08-27 18:53, John Petrini wrote:
Hi List,
I'm seeing corruption errors when running btrfs device stats but I'm
not sure what that means exactly. I've just completed a full scrub and
it reported no errors. I'm hoping someone here can enlighten me.
Thanks!
The first thing to understand h
On 2018-08-27 17:05, Eugene Bright wrote:
Greetings!
BTRFS wiki says there is no per-subvolume compression option [1].
At the same time next command allow me to set properties per-subvolume:
btrfs property set /volume compression zstd
Corresponding get command shows distinct propertie
Hi all
I have run a distro upgrade on my Ubuntu 16.04 that runs ppa kernel
4.17.2 with btrfsprogs 4.17.0
The root filesystem is BTRFS single created by the Ubuntu Xenial
installer (so on kernel 4.4.0) on an internal mmc, located in
/dev/mmcblk0p3
After the upgrade I have cleaned apt cache and check
On 28.08.2018 09:46, Qu Wenruo wrote:
> Although we have space_info::bytes_may_use underflow detection in
> btrfs_free_reserved_data_space_noquota(), we have more callers who are
> subtracting number from space_info::bytes_may_use.
>
> So instead of doing underflow detection for every caller, i
On 2018/8/28 下午1:54, Qu Wenruo wrote:
> Due to the limitation of btrfs_cross_ref_exist(), run_delalloc_nocow()
> can still fall back to CoW even only (unrelated) part of the
> preallocated extent is shared.
>
> This makes the follow case to do unnecessary CoW:
>
> # xfs_io -f -c "falloc 0 2M"
39 matches
Mail list logo