On 2018年03月01日 02:36, Filipe Manana wrote:
> On Wed, Feb 28, 2018 at 5:50 PM, David Sterba <dste...@suse.cz> wrote:
>> On Wed, Feb 28, 2018 at 05:43:40PM +0100, peteryuchu...@gmail.com wrote:
>>> On my laptop, which has just been switched to BTRFS, the root partition
>>> (a BTRFS partition inside an encrypted LVM. The drive is an NVMe) is
>>> re-mounted as read-only few minutes after boot.
>>>
>>> Trace:
>>
>> By any chance, are there other messages from btrfs above the line?
>>>
>>> [ 199.974591] ------------[ cut here ]------------
>>> [ 199.974593] BTRFS: Transaction aborted (error -95)
>>
>> -95 is EOPNOTSUPP, ie operation not supported
>>
>>> [ 199.974647] WARNING: CPU: 0 PID: 324 at fs/btrfs/inode.c:3042
>>> btrfs_finish_ordered_io+0x7ab/0x850 [btrfs]
>>
>> btrfs_finish_ordered_io::
>>
>> 3038 btrfs_ordered_update_i_size(inode, 0, ordered_extent);
>> 3039 ret = btrfs_update_inode_fallback(trans, root, inode);
>> 3040 if (ret) {
>> 3041 btrfs_abort_transaction(trans, ret);
>> 3042 goto out;
>> 3043 }
>
> I don't know what's exactly in Arch's kernel, but looking at the
> 4.15.5 stable tag from kernel.org:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/fs/btrfs/inode.c?h=v4.15.5#n3042
>
> The -EOPNOTSUPP error can come from btrfs_drop_extents() through the
> call to insert_reserved_file_extent().__btrfs_drop_extents() will return -EOPNOTSUPP if we're dropping part of an inline extent. Could be something wrong with convert inline extent generator. > We've had several reports of this kind of error in this location in > the past and they happened to be on filesystems converted from extN to > btrfs. > I don't know however if this filesystem was from such a conversion nor > if those old bugs in the conversion tool were fixed. And since the user is using Arch and kernel is latest, it normally means the btrfs-progs is also latest. I need to double check about the convert inline extent code to ensure we don't create too large inline extent. Thanks, Qu > > >> >> the return code is unexpected here. And seeing 'operation not supported' >> after a inode size change looks strange but EOPNOTSUPP could be returned >> from some places. >> >> The transaction is aborted from a thread that finalizes some processing >> so we don't have enough information here to see how it started. I >> suspect there's a file that gets modified short after boot and hits the >> problem. I don't think the EOPNOTSUPP is returned from the lower layers >> (lvm encryption or nvme), so at this point seems like a btrfs bug. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > >
signature.asc
Description: OpenPGP digital signature
