Commit edf064e7c (btrfs: nowait aio support) breaks shells

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

Re: Deleting mounted subvolumes

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

ping on patches..

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

Re: Deleting mounted subvolumes

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

Re: Deleting mounted subvolumes

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

Re: Deleting mounted subvolumes

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 >>>

Re: Deleting mounted subvolumes

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

Re: [RFC PATCH v4 2/2] Btrfs: add heuristic method for make decision compress or not compress

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 > +++

Re: [RFC PATCH v4 0/2] Btrfs: add compression heuristic

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

Re: kernel BUG at /home/kernel/COD/linux/fs/btrfs/extent_io.c:2328 when replacing disk

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:

Known bugs in v4,.11.0?

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 -

kernel BUG at /home/kernel/COD/linux/fs/btrfs/extent_io.c:2328 when replacing disk

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

Temporary changes regarding btrfs branch in linux-next and development patches

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

Re: [PATCH 1/2] btrfs-progs: Fix false alert about EXTENT_DATA shouldn't be hole

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]

Re: [PATCH v2] btrfs: fix validation of XATTR_ITEM dir items

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