4.6.1 crash probably during find

Hello, System crashed. SysRq stilled worked. btrfs check does not find error on any filesystem. [82275.348754] general protection fault: [#1] PREEMPT SMP [82275.354640] Modules linked in: cp210x usbserial rc_digittrade mt2060 af9013 uas intel_rapl kvm_intel dvb_usb_af9015 dvb_usb_v2

Re: [PATCH v3] btrfs: fix check_shared for fiemap ioctl

On Wed, Jun 08, 2016 at 01:13:03PM +0800, Lu Fengqi wrote: > Only in the case of different root_id or different object_id, check_shared > identified extent as the shared. However, If a extent was referred by > different offset of same file, it should also be identified as shared. > In addition,

Replacing drives with larger ones in a 4 drive raid1

Dear list I've had a 4 drive btrfs raid1 setup in my backup NAS for a few months now. It's running Fedora 23 Server with kernel 4.5.5 and btrfs-progs v4.4.1. Recently I had the idea to replace the 6 TB HDDs with 8 TB ones ("WD Red"), because their price is now acceptable. (More back story:

Re: btrfs filesystem keeps allocating new chunks for no apparent reason

Hi list, On 05/31/2016 03:36 AM, Qu Wenruo wrote: Hans van Kranenburg wrote on 2016/05/06 23:28 +0200: Hi, I've got a mostly inactive btrfs filesystem inside a virtual machine somewhere that shows interesting behaviour: while no interesting disk activity is going on, btrfs keeps allocating

Re: check if hardware checksumming works or not

I was hoping for a more advanced method than just blacklisting drivers. :) Anyways, it seems that first june there was a patch [PATCH] btrfs: advertise which crc32c implementation is being used at module load that is getting merged lately, so In the near future I will be able to see on

[PULL] Btrfs, misc fixes for 4.7-rc3

Hi, a small set of fixes, a build fix and one minor enhancemen that will tell us the crc32 implementation used. Please pull, thanks. The following changes since commit 56244ef151c3cd11f505020ab0b3f45454363bcc: Btrfs: fix handling of faults from btrfs_copy_from_user (2016-05-26 13:23:59

Can't remove read-only snapshot with immutable flag set

Hi! It happened that I set the immutable flag (via `chattr +i`) on a subvolume. Then I made a read-only snapshot of that subvolume. Now I can't remove this snapshot. #> btrfs subvolume delete my_snapshot Delete subvolume (no-commit): 'my_snapshot' ERROR: cannot

Btrfs progs pre-release 4.6-rc1

Hi, the next major version 4.6 is about to be released, ETA tomorrow. The biggest change is the btrfs-convert rewrite. The delayed release was caused by more testing as there were some late fixes to the code although the patchset has been in the development branch for a long time. Apart from

Re: Can't remove read-only snapshot with immutable flag set

On Wed, 8 Jun 2016 08:37:57 + cdlscpmv wrote: > It happened that I set the immutable flag (via `chattr +i`) on a subvolume. > Then I made a read-only snapshot of that subvolume. Now I can't remove > this snapshot. > > #> btrfs subvolume delete my_snapshot >

Re: Can't remove read-only snapshot with immutable flag set

On Wednesday, June 8, 2016, cdlscpmv wrote: > > Hi! > > It happened that I set the immutable flag (via `chattr +i`) on a subvolume. > Then I made a read-only snapshot of that subvolume. Now I can't remove > this snapshot. > > #> btrfs subvolume delete my_snapshot >

Re: Can't remove read-only snapshot with immutable flag set

On 2016/06/08 06:47:52 -0400, Noah Massey wrote: > On Wednesday, June 8, 2016, cdlscpmv wrote: > > > > Hi! > > > > It happened that I set the immutable flag (via `chattr +i`) on a subvolume. > > Then I made a read-only snapshot of that subvolume. Now I can't remove > > this

Re: btrfs

Christoph Anton Mitterer posted on Sun, 05 Jun 2016 23:31:57 +0200 as excerpted: >> > Wasn't it said, that autodefrag performs bad for anything larger than >> > ~1G? >> >>    I don't recall ever seeing someone saying that. Of course, I may >> have forgotten seeing it... > I think it was

[PATCH 00/21] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros. The macros are not y2038 safe. There is no plan to transition them into being y2038 safe. ktime_get_* api's can be used in their place. And, these are y2038 safe. All filesystem timestamps use current_fs_time() for

[PATCH] btrfs-progs: add the error message when open fails

When open in btrfs_open_devices failed, only the following message is displayed. Therefore the user doesn't understand the reason why open failed. # btrfs check /dev/sdb8 Couldn't open file system This patch adds the error message when open fails. Signed-off-by: Tsutomu Itoh