btrfs_sync_file alignment trap on arm (kernel 4.2.5)

Ideas as to what could cause this would be appreciated. This consistently is triggered shortly after boot (I presume due to conmand calling fsync on a file). Note that I'm not quite running 4.2.5, but none of the changes I have additionally applied are to btrfs or atomics. Let me know if there

Re: Unable to allocate for space usage in particular btrfs volume

On Wed, Nov 04, 2015 at 09:10:42PM +, OmegaPhil wrote: > Back in September I noticed that 'sudo du -chs /mnt/storage-1' reported > 887GB used and 'df -h' 920GB for this particular volume - I went on > #btrfs for any suggestions, and balancing + defraging made no > difference. It had no

Re: Unable to allocate for space usage in particular btrfs volume

On 04/11/15 21:30, Hugo Mills wrote: > On Wed, Nov 04, 2015 at 09:10:42PM +, OmegaPhil wrote: >> Back in September I noticed that 'sudo du -chs /mnt/storage-1' reported >> 887GB used and 'df -h' 920GB for this particular volume - I went on >> #btrfs for any suggestions, and balancing +

Unable to allocate for space usage in particular btrfs volume

Back in September I noticed that 'sudo du -chs /mnt/storage-1' reported 887GB used and 'df -h' 920GB for this particular volume - I went on #btrfs for any suggestions, and balancing + defraging made no difference. It had no subvolumes/snapshots etc, I basically used it like a checksumed ext4fs.

[PATCH v3] btrfs: qgroup: exit the rescan worker during umount

I was hitting a consistent NULL pointer dereference during shutdown that showed the trace running through end_workqueue_bio(). I traced it back to the endio_meta_workers workqueue being poked after it had already been destroyed. Eventually I found that the root cause was a qgroup rescan that was

[PATCH v2] btrfs: test unmount during quota rescan

This test case tests if we are able to unmount a filesystem while a quota rescan is running. Up to now (4.3) this would result in a kernel NULL pointer dereference. Fixed by patch (btrfs: qgroup: exit the rescan worker during umount). Signed-off-by: Justin Maggard ---

Re: [PATCH 0/5] Btrfs: Per-chunk degradable check

Any new comment? And to Chris, is it possible to pick these patchset for 4.4? IMHO it's small enough (less than 100 lines) and didn't change degraded mount behavior much. Thanks, Qu Qu Wenruo wrote on 2015/09/21 10:10 +0800: Btrfs currently uses num_tolerated_disk_barrier_failures to do

Re: Btrfs/RAID5 became unmountable after SATA cable fault

Austin S Hemmelgarn posted on Wed, 04 Nov 2015 13:45:37 -0500 as excerpted: > On 2015-11-04 13:01, Janos Toth F. wrote: >> But the worst part is that there are some ISO files which were >> seemingly copied without errors but their external checksums (the one >> which I can calculate with md5sum

Re: Unable to allocate for space usage in particular btrfs volume

OmegaPhil posted on Wed, 04 Nov 2015 21:53:09 + as excerpted: > The volume doesn't change hugely over time, so it really ought not to > have broken so quickly - a quick rundown of the storage usage: > > 36% general (small files, some smallish videos) > 24% music 23% pr0n 17% VMs > > But in

Re: 4.2.5 forced read-only -ENOSPC w/ free space

FYI, 4.1.12 completed the big rsync without issues. Guess I'm using longterm for now. On Mon, Nov 2, 2015 at 9:53 AM, E V wrote: > During an rsync, 20TB unallocated space. Currently, no snapshots. > Should I try 4.1.12, or 4.3? > dmesg: > [122014.436612] BTRFS: error (device

Re: Btrfs/RAID5 became unmountable after SATA cable fault

Well. Now I am really confused about Btrfs RAID-5! So, I replaced all SATA cables (which are explicitly marked for beeing aimed at SATA3 speeds) and all the 3x2Tb WD Red 2.0 drives with 3x4Tb Seagate Contellation ES 3 drives and started from sratch. I secure-erased every drives, created an empty

Re: Btrfs/RAID5 became unmountable after SATA cable fault

On 2015-11-04 13:01, Janos Toth F. wrote: But the worst part is that there are some ISO files which were seemingly copied without errors but their external checksums (the one which I can calculate with md5sum and compare to the one supplied by the publisher of the ISO file) don't match! Well...

[PATCH] Btrfs: fix extent accounting for partial direct IO writes

From: Filipe Manana When doing a write using direct IO we can end up not doing the whole write operation using the direct IO path, in that case we fallback to a buffered write to do the remaining IO. This happens for example if the range we are writing to contains a compressed

[PATCH] fstests: test for btrfs direct IO write against compressed extent

From: Filipe Manana Test that doing a direct IO write against a file range that contains one prealloc extent and one compressed extent works correctly. >From the linux kernel 4.0 onwards, this either triggered an assertion failure (leading to a BUG_ON) when

[PATCH v2] fstests: generic test for fsync after hole punching

From: Filipe Manana Test that a file fsync works after punching a hole for the same file range multiple times, and that after log/journal replay the file's content and layout are correct. This test is motivated by a bug found in btrfs, which is fixed by the following linux