I don't actually think that this is a BTRFS problem, but it's showing
symptoms within BTRFS, and I have no other clues, so maybe the BTRFS
experts can help me figure out what is actually going wrong.
I'm a sysadmin working for a company that does scientific modelling.
They have many TBs of data.
On Tue, Aug 11, 2015 at 12:32:01PM +1000, Dave Chinner wrote:
> On Mon, Aug 10, 2015 at 04:12:59PM +0800, Liu Bo wrote:
> > Regression test for btrfs defragment tool, it's aimed to verify
> > that tail extents won't be skipped as a separate extent while the previous
> > extents have been defrag'ed
On Mon, Aug 10, 2015 at 10:17:52AM +0100, Filipe David Manana wrote:
> On Mon, Aug 10, 2015 at 9:12 AM, Liu Bo wrote:
> > Regression test for btrfs defragment tool, it's aimed to verify
> > that tail extents won't be skipped as a separate extent while the previous
> > extents have been defrag'ed i
Hi all,
Starting today I have an interesting problem: I deleted some files as part (old
fcrontabs), which now persistently causes btrfs-send to fail. The error
message I get is:
Aug 12 23:32:24 thetick make_backups.sh[1059]: ERROR: send ioctl failed with
-2: No such file or directory
Aug 12 23:
Ok, here's what's happening. A few years ago, I took my old WD green
drives and put them in a box as backups to a new array of Seagate
drives. When one of those seagate drives failed (just out of
warranty, of course), I replaced it with one of the WD's. That was
cooking along just fine until jus
Actually, it didn't resume. The "btrfs delete missing" was using 100%
of the I/O bandwidth but wasn't actually doing any disk reads of
writes. I tried to reboot, but the system wouldn't go down, so after
waiting 10 minutes, I power-cycled. Now I can't mount at all and
here's what dmesg says abou
It resumed on its own. Weird.
On Wed, Aug 12, 2015 at 4:23 PM, Timothy Normand Miller
wrote:
> On Wed, Aug 12, 2015 at 2:10 PM, Chris Murphy wrote:
>
>>
>> Anyway it looks like it's hardware related, but I don't know what
>> device ata4.00 is, so maybe this helps:
>> http://superuser.com/questi
On Wed, Aug 12, 2015 at 2:10 PM, Chris Murphy wrote:
>
> Anyway it looks like it's hardware related, but I don't know what
> device ata4.00 is, so maybe this helps:
> http://superuser.com/questions/617192/mapping-ata-device-number-to-logical-device-name
# ata=4; ls -l /sys/block/sd* | grep $(gre
Thanks, this is helpful.
We are primarily scaling the number of snapshots. Unfortunately these
snapshots typically have very minor changes compared their parent, so
this sounds potentially problematic.
It sounds like I will need to do some testing of both snapshots and
quotas to determine scalabi
On Mon, Aug 10, 2015 at 6:13 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> We do recommend that you stay relatively current on both kernel and
> userspace, however. So a current 4.1 series kernel and btrfs-progs 4.1.2
> are excellent, but consider another filesystem if you're the type who was
> stil
On Wed, Aug 12, 2015 at 12:44 PM, Konstantin Svist wrote:
> On 08/06/2015 04:10 AM, Austin S Hemmelgarn wrote:
>> On 2015-08-05 17:45, Konstantin Svist wrote:
>>> Hi,
>>>
>>> I've been running btrfs on Fedora for a while now, with bedup --defrag
>>> running in a night-time cronjob.
>>> Last few ru
On 08/06/2015 04:10 AM, Austin S Hemmelgarn wrote:
> On 2015-08-05 17:45, Konstantin Svist wrote:
>> Hi,
>>
>> I've been running btrfs on Fedora for a while now, with bedup --defrag
>> running in a night-time cronjob.
>> Last few runs seem to have gotten stuck, without possibility of even
>> killin
On Tue, Aug 11, 2015 at 12:18 PM, Catalin wrote:
> I have a recently installed an Arch Linux x86_64 system on a 50GB
> btrfs partition and every time I try btrfs balance start it gives me
> an enospc error even though I have less than 20% of the available
> space full.
>
> I have tried the recommen
There are hardware problems here...
[112531.319224] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[112531.319231] ata4.00: failed command: WRITE DMA EXT
[112531.319240] ata4.00: cmd 35/00:00:00:8d:46/00:04:08:00:00/e0 tag 0
dma 524288 out
res 40/00:00:00
I added a new device and then did a delete missing. I lost the
terminal (should have used gnu screen), so I didn't see the stdout,
but the operation aborted at some point. There's ton of output in
dmesg related to this, along with some OOPSes, which I have attached
as "dmesg2" here:
https://bugz
On Wed, Aug 12, 2015 at 11:43 AM, Hugo Mills wrote:
> [adding Ulli back into the cc list]
>
> On Wed, Aug 12, 2015 at 11:03:00AM -0600, Chris Murphy wrote:
>> On Wed, Aug 12, 2015 at 7:07 AM, Ulli Horlacher
>> wrote:
>>
>> > /dev/sdb and /dev/sde are in reality the same physical disk!
>>
>> When
[adding Ulli back into the cc list]
On Wed, Aug 12, 2015 at 11:03:00AM -0600, Chris Murphy wrote:
> On Wed, Aug 12, 2015 at 7:07 AM, Ulli Horlacher
> wrote:
>
> > /dev/sdb and /dev/sde are in reality the same physical disk!
>
> When does all of this confusion happen? Is it already confused befo
On Wed, Aug 12, 2015 at 12:18:45PM -0400, Josef Bacik wrote:
> Going to need more info to figure this one out
Thanks for the patch, here's the output:
enabling repair mode
Checking filesystem on /dev/mapper/crypt_sdd1
UUID: 024ba4d0-dacb-438d-9f1b-eeb34083fe49
checking extents
wtf, parent 5757084
On Wed, Aug 12, 2015 at 7:07 AM, Ulli Horlacher
wrote:
> /dev/sdb and /dev/sde are in reality the same physical disk!
When does all of this confusion happen? Is it already confused before
mkfs or only after mkfs or only after mount? I would find out what
instigates it, wipe all signatures from e
On 08/12/2015 12:09 PM, Marc MERLIN wrote:
On Wed, Aug 12, 2015 at 11:15:39AM -0400, Josef Bacik wrote:
On 08/12/2015 10:47 AM, Marc MERLIN wrote:
On Tue, Aug 11, 2015 at 11:40:45AM -0400, Josef Bacik wrote:
From a48cf7a9ae44a17d927df5542c8b0be287aee9ed Mon Sep 17 00:00:00 2001
From: Josef Ba
On Wed, Aug 12, 2015 at 11:15:39AM -0400, Josef Bacik wrote:
> On 08/12/2015 10:47 AM, Marc MERLIN wrote:
> >On Tue, Aug 11, 2015 at 11:40:45AM -0400, Josef Bacik wrote:
> >> From a48cf7a9ae44a17d927df5542c8b0be287aee9ed Mon Sep 17 00:00:00 2001
> >>From: Josef Bacik
> >>Date: Tue, 11 Aug 2015 11:
On Wed, Aug 12, 2015 at 03:44:51PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> While we are committing a transaction, it's possible the previous one is
> still finishing its commit and therefore we wait for it to finish first.
> However we were not checking if that previous transa
On 08/12/2015 10:47 AM, Marc MERLIN wrote:
On Tue, Aug 11, 2015 at 11:40:45AM -0400, Josef Bacik wrote:
From a48cf7a9ae44a17d927df5542c8b0be287aee9ed Mon Sep 17 00:00:00 2001
From: Josef Bacik
Date: Tue, 11 Aug 2015 11:39:37 -0400
Subject: [PATCH] Btrfs: kill BUG_ON() in btrfs_lookup_extent_in
On Tue, Aug 11, 2015 at 11:40:45AM -0400, Josef Bacik wrote:
> From a48cf7a9ae44a17d927df5542c8b0be287aee9ed Mon Sep 17 00:00:00 2001
> From: Josef Bacik
> Date: Tue, 11 Aug 2015 11:39:37 -0400
> Subject: [PATCH] Btrfs: kill BUG_ON() in btrfs_lookup_extent_info()
>
> Replace it with an ASSERT(0)
From: Filipe Manana
While we are committing a transaction, it's possible the previous one is
still finishing its commit and therefore we wait for it to finish first.
However we were not checking if that previous transaction ended up getting
aborted after we waited for it to commit, so we ended up
On 08/12/2015 10:11 AM, fdman...@kernel.org wrote:
From: Filipe Manana
While we are committing a transaction, it's possible the previous one is
still finishing its commit and therefore we wait for it to finish first.
However we were not checking if that previous transaction ended up getting
abo
From: Filipe Manana
While we are committing a transaction, it's possible the previous one is
still finishing its commit and therefore we wait for it to finish first.
However we were not checking if that previous transaction ended up getting
aborted after we waited for it to commit, so we ended up
I have 2 identical servers with 2 x 2 Hitachi (HGST) SATA disks (and some
other disks) which are mirrored with drbd.
On top of this drbd setup I have created a btrfs RAID0 filesystem.
The problem now is, that btrfs shows the raw device instead of the drbd
device.
root@toy02:~# mkfs.btrfs /dev/drb
On Wed 05-08-15 09:49:24, Greg Thelen wrote:
>
> mho...@kernel.org wrote:
>
> > From: Michal Hocko
> >
> > Journal transaction might fail prematurely because the frozen_buffer
> > is allocated by GFP_NOFS request:
> > [ 72.440013] do_get_write_access: OOM for frozen_buffer
> > [ 72.440014] E
On Tue, Aug 11, 2015 at 11:33:45AM -0700, Tristan Zajonc wrote:
> In an early thread Duncan mentioned that btrfs does not scale well in
> the number of subvolumes (including snapshots). He recommended
> keeping the total number under 1000. I just wanted to understand this
> limitation further. I
From: Kent Overstreet
Btrfs has been doing bio splitting from btrfs_map_bio(), by checking
device limits as well as calling ->merge_bvec_fn() etc. That is not
necessary any more, because generic_make_request() is now able to
handle arbitrarily sized bios. So clean up unnecessary code paths.
Cc:
31 matches
Mail list logo
