commit edf064e7c6fec3646b06c944a8e35d1a3de5c2c3 (HEAD, refs/bisect/bad)
Author: Goldwyn Rodrigues
Date: Tue Jun 20 07:05:49 2017 -0500
btrfs: nowait aio support
apparently breaks several shell related features on my system.
In zsh history stopped working, because no new entries are added
a
04.07.2017 02:21, Chris Murphy пишет:
> It's more like a bind mount of a directory, as far as what's going on
> under the hood. I take it it's possible to delete a directory that is
> bind mounted elsewhere?
Yes, it is. Usual rules apply - it must be empty, but "rm -r" works as
well (and is more o
Hi David,
Couple of patches waiting for your response ..
[PATCH] btrfs: check options during subsequent mount
[PATCH] btrfs: add mount umount logs
cheers, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
Mo
Chris Murphy posted on Mon, 03 Jul 2017 17:21:18 -0600 as excerpted:
> It's more like a bind mount of a directory, as far as what's going on
> under the hood. I take it it's possible to delete a directory that is
> bind mounted elsewhere? I'm not sure what happens though.
Yes, deleting a director
It's more like a bind mount of a directory, as far as what's going on
under the hood. I take it it's possible to delete a directory that is
bind mounted elsewhere? I'm not sure what happens though.
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body
On 07/03/2017 10:48 PM, Pete wrote:
> On 07/03/2017 12:30 AM, Hans van Kranenburg wrote:
>> On 07/02/2017 11:33 PM, Pete wrote:
>>> I found that I can delete a mounted subvolume using:
>>> btrfs subvolume delete
>>>
>>> This works. Is this the intended action? To me it would seem like a
>>> warn
On 07/03/2017 12:30 AM, Hans van Kranenburg wrote:
> On 07/02/2017 11:33 PM, Pete wrote:
>> I found that I can delete a mounted subvolume using:
>> btrfs subvolume delete
>>
>> This works. Is this the intended action? To me it would seem like a
>> warning and the command exiting would make sense
On Sat, Jul 01, 2017 at 07:56:02PM +0300, Timofey Titovets wrote:
> Add a heuristic computation before compression,
> for avoiding load resource heavy compression workspace,
> if data are probably can't be compressed
>
> Signed-off-by: Timofey Titovets
> --- /dev/null
> +++ b/fs/btrfs/heuristic.c
On Sat, Jul 01, 2017 at 07:56:00PM +0300, Timofey Titovets wrote:
> Today btrfs use simple logic to make decision
> compress data or not:
> Selected compression algorithm try compress
> data and if this save some space
> store that extent as compressed.
>
> It's Reliable way to detect uncompressib
Hi,
I upgraded to 4.12 (instead of the rc) and the problem continues:
# uname -a
Linux ubuntu-server 4.12.0-041200rc7-generic #201706252231 SMP Mon Jun
26 02:33:00 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ btrfs --version
btrfs-progs v4.4
# btrfs fi show
Label: none uuid: 48ed8a66-731d-499b-
We're running a openstack deployment using kolla-ansible on machines
with btrfs filesystems.
kolla-ansible deploys everything as docker images, which in turn uses
btrfs subvolumes and does some heavy-magic^tm
Anyway, a while ago, we restarted one docker instance on four
machines, as you do - pret
Hi,
I'm replacing a btrfs device that was set up as a partition with one
that is a whole disk.
The replace is getting stuck at the 53% mark with errors: kernel BUG at
/home/kernel/COD/linux/fs/btrfs/extent_io.c:2328
More info below -- rebooting and letting replace continue seems to not
res
Hi,
in order to allow merging new btrfs patches and also keep linux-next merging
sane [1], I'm going to freeze any changes to my k.org [2] branch for-next until
4.13-rc1 is released, expecting that the conflicting branches get merged as
well.
* k.org for-next will contain only the upcoming pull r
On Mon, Jun 19, 2017 at 1:26 PM, Henk Slager wrote:
> On 16-06-17 03:43, Qu Wenruo wrote:
>> Since incompat feature NO_HOLES still allow us to have explicit hole
>> file extent, current check is too restrict and will cause false alert
>> like:
>>
>> root 5 EXTENT_DATA[257, 0] shouldn't be hole
>>
Thanks a lot.
I'm sorry for that I hadn't noticed those emails during the vacation.
On 06/30/2017 02:20 AM, David Sterba wrote:
The XATTR_ITEM is a type of a directory item so we use the common
validator helper. Unlike other dir items, it can have data. The way the
name len validation is current
15 matches
Mail list logo