Hi All,
I just released a toy program, "fienode" which computes a SHA1 of the
physical extents of a file.
Link: https://github.com/pwaller/fienode
There are some questions around on the internet of how to find CoW
copies, which I've answered:
http://unix.stackexchange.com/questions/263309/how-t
In the same vein, I've also made
https://github.com/pwaller/sharedextents - which exits with status 0
when there are shared extents, and 1 otherwise; it also prints the
number and percentage of shared bytes.
Here it is running on the file and its reflink copy from "A BTRFS
mystery" in the previous
Hi All,
I've reported a bug with Ubuntu here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349711
The machine in question has one BTRFS volume which is 87% full and
lives on an Logical Volume Manager (LVM) block device on top of one
Amazon Elastic Block Store (EBS) device.
We have other
think that maybe the latter was
unnecessary.
On 29 July 2014 09:04, Peter Waller wrote:
> Hi All,
>
> I've reported a bug with Ubuntu here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349711
>
> The machine in question has one BTRFS volume which is 87% full and
t; [1093202.152585] [] worker_thread+0x121/0x410
> [1093202.152588] [] ? rescuer_thread+0x3e0/0x3e0
> [1093202.152591] [] kthread+0xd2/0xf0
> [1093202.152594] [] ? kthread_create_on_node+0x1d0/0x1d0
> [1093202.152598] [] ret_from_fork+0x7c/0xb0
> [1093202.152601] [] ? kthread_create_on_node+0x1
The lockup seems to be reliably stuck in btrfs_find_space_cluster.
kernel log with 10s traces is linked to below (3.16.0-031600rc7-generic)
https://gist.github.com/pwaller/d40df3badb5cc8a574ef
On 30 July 2014 11:02, Peter Waller wrote:
> The crashes became more frequent. The time scale befor
I should add that I have reproduced this even after doing `mount -o
clear_cache /dev/... /mnt/...`, unmount, remount with `-o
space_cache`. After the machine lockup and rebooting there are the
warnings of the form:
> [ 117.288248] BTRFS warning (device dm-0): block group 694165700608 has wrong
>
I've reproduced these issues on a single-core machine which doesn't
appear to become completely unresponsive after 12 hours of copying (as
the other machines are deadlocking after 5-10 minutes, perhaps?), but
it does use 100% SYS CPU with no IO traffic for the vast majority of
the time. (In fact, c
Hi All,
My TL;DR questions are at the bottom, before the stack trace.
I'm running Ubuntu 14.04. I wonder if this problem is related to the
thread titled "Machine lockup due to btrfs-transaction on AWS EC2
Ubuntu 14.04" which I started on the 29th of July:
> http://thread.gmane.org/gmane.comp.fil
just that no-one has gotten around to yet?
Thanks,
- Peter
On 4 August 2014 02:38, Qu Wenruo wrote:
> Hi, Peter
>
> Some explain below inline.
>
> ---- Original Message
> Subject: ENOSPC with mkdir and rename
> From: Peter Waller
> To:
> Date: 2014年08
On 4 August 2014 10:39, Chris Samuel wrote:
> On Mon, 4 Aug 2014 09:14:19 AM Peter Waller wrote:
>> All of this is *very* surprising.
>
> Hmm, it shouldn't be, the ENOSPC issues are well known and have been discussed
> here for years.
I accept that. It's all very wel
On 4 August 2014 11:39, Hugo Mills wrote:
>> > * btrfs fi df
>> > - look at metadata used vs total. If these are close to zero (on
>> > 3.15+) or close to 512 MiB (on <3.15), then you are in danger of
>> > ENOSPC.
>>
>> Hmm. It's unfortunate that this could indicate an amount of s
Thanks Hugo, this is the most informative e-mail yet! (more inline)
On 4 August 2014 11:22, Hugo Mills wrote:
>
> * btrfs fi show
> - look at the total and used values. If used < total, you're OK.
> If used == total, then you could potentially hit ENOSPC.
Another thing which is unclea
On 4 August 2014 11:50, Chris Samuel wrote:
> To be honest I'm not sure I'd suggest btrfs for production use at all at
> present, it's only recently been unmarked as experimental and to be honest I
> feel that was premature. :-(
Thanks for the honest answer.
There are very positive signals out t
For anyone else having this problem, this article is fairly useful for
understanding disk full problems and rebalance:
http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html
It actually covers the problem that I had, which is that a rebalance
can't take pla
On 4 August 2014 15:02, Austin S Hemmelgarn wrote:
> I really disagree with the statement that adding more storage is
> difficult or expensive, all you need to do is plug in a 2G USB flash
> drive, or allocate a ramdisk, and add the device to the filesystem only
> long enough to do a full balance.
I already posted this in the thread "ENOSPC with mkdir and rename",
but now I have a device with 100GB unallocated on the "btrfs fi sh"
output, and when I run a rebalance of the form:
> btrfs filesystem balance start -dusage=50 -musage=10 "$mount"
I get more than 75 of such stack traces contamina
On 5 August 2014 10:46, Hugo Mills wrote:
>It's a warning, not an oops, so it's less immediately dangerous.
> The other key thing is "block rsv returned -28", which says it's an
> ENOSPC. My guess would be that you've got ENOSPC debugging enabled in
> the kernel, and that the backtraces, while
My current interpretation of this problem is that it is some
pathological condition caused by not rebalancing and being nearly out
of space for allocating more metadata and hence it is rarely being
seen by anyone else (because most users are regularly doing
rebalances).
See this thread for details
On 5 August 2014 13:58, Clemens Eisserer wrote:
> As long as it is not selected as the default filesystem, I think it is fine.
> Other distributions have been offering btrfs for some time now, too.
How do you warn non-BTRFS-developers in this case that they need to
run a regular rebalance or they
Apologies to those receiving this twice.
On 27 December 2014 at 09:30, Hugo Mills wrote:
>
> Now, since you're seeing lockups when the space on your disks is
>
> all allocated I'd say that's a bug. However, you're the *only* person
>
> who's reported this as a regular occurrence. Does this happen
Further to the old thread: "Machine lockup due to btrfs-transaction on
AWS EC2 Ubuntu 14.04":
http://thread.gmane.org/gmane.comp.file-systems.btrfs/37224
Since I have done a nightly rebalance and ensured plenty of
unallocated space, the main 3 btrfs machines have behaved themselves
for almost a m
22 matches
Mail list logo
