> >
> > No, I see why you choose to add the flag to open(2).
> > I have no objection.
> >
> > I once had a crazy thought how to add new open flags
> > in a non racy manner without adding a new syscall,
> > but as you wrote, this is not relevant for O_ALLOW_ENCODED.
> >
> > Something like:
> >
> > /
On 2019-10-19, Aleksa Sarai wrote:
> On 2019-10-15, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > The upcoming RWF_ENCODED operation introduces some security concerns:
> >
> > 1. Compressed writes will pass arbitrary data to decompression
> >algorithms in the kernel.
> > 2. Compress
On 2019-10-22, Amir Goldstein wrote:
> On Mon, Oct 21, 2019 at 9:54 PM Omar Sandoval wrote:
> >
> > On Mon, Oct 21, 2019 at 09:18:13AM +0300, Amir Goldstein wrote:
> > > CC: Ted
> > >
> > > What ever happened to read/write ext4 encrypted data API?
> > > https://marc.info/?l=linux-ext4&m=145030599
On Fri, Oct 18, 2019 at 08:07:28PM -0700, Marc MERLIN wrote:
> Ok, so before blowing the filesystem away after it was apparently badly
> damaged by a suspend to disk, I tried check --repair and I hit an
> infinite loop.
>
> Let me know if you'd like anything off the FS before I delete it.
I heard
On 2019/10/23 上午6:56, Christian Pernegger wrote:
> [Please CC me, I'm not on the list.]
>
> Am Mo., 21. Okt. 2019 um 15:34 Uhr schrieb Qu Wenruo :
>> [...] just fstrim wiped some old tree blocks. But maybe it's some
>> unfortunate race, that fstrim trimmed some tree blocks still in use.
>
> Fo
[Please CC me, I'm not on the list.]
Am Mo., 21. Okt. 2019 um 15:34 Uhr schrieb Qu Wenruo :
> [...] just fstrim wiped some old tree blocks. But maybe it's some unfortunate
> race, that fstrim trimmed some tree blocks still in use.
Forgive me for asking, but assuming that's what happened, why are
On Tue, Oct 22, 2019 at 03:52:07PM +0200, David Sterba wrote:
> * fix during file sync, the full-sync status might get dropped
> externally, eg. by background witeback under some circumstances
Please replace the above merge log entry with
* fix race when handling full sync flag
The above wordi
On Mon, Oct 07, 2019 at 09:37:40PM +0200, David Sterba wrote:
> The extent_map::bdev is unused and and can be removed, but it's not
> straightforward so there are several steps. The first patch decouples
> bdev from map_lookup. The remaining patches clean up use of the bdev,
> removing a few bio_se
Hi,
please pull the following updates, all stable material.
Thanks.
Changes:
* fixes of error handling cleanup of metadata accounting with qgroups
enabled
* fix swapped values for qgroup tracepoints
* fix during file sync, the full-sync status might get dropped
externally, eg. by backgroun
On Tue, Oct 22, 2019 at 03:45:38PM +0300, Nikolay Borisov wrote:
>
>
> On 22.10.19 г. 5:02 ч., Marcos Paulo de Souza wrote:
> > From: Marcos Paulo de Souza
> >
> > While compiling btrfs-progs using clang I found an issue using
> > __attribute__(fallthrough), which does not seems to work in clan
On 2019-10-22 06:01, Qu Wenruo wrote:
On 2019/10/22 下午5:47, Tobias Reinhard wrote:
Hi,
I noticed that if you punch a hole in the middle of a file the available
filesystem space seems not to increase.
Kernel is 5.2.11
To reproduce:
->mkfs.btrfs /dev/loop1 -f
btrfs-progs v4.15.1
See http:/
On Mon, Oct 21, 2019 at 11:02:26PM -0300, Marcos Paulo de Souza wrote:
> From: Marcos Paulo de Souza
>
> While compiling btrfs-progs using clang I found an issue using
> __attribute__(fallthrough), which does not seems to work in clang.
>
> To solve this issue, the code was changed to use /* fal
On 22.10.19 г. 5:02 ч., Marcos Paulo de Souza wrote:
> From: Marcos Paulo de Souza
>
> While compiling btrfs-progs using clang I found an issue using
> __attribute__(fallthrough), which does not seems to work in clang.
>
> To solve this issue, the code was changed to use /* fallthrough */, wh
On 2019/10/22 下午8:23, David Sterba wrote:
> On Tue, Oct 22, 2019 at 02:30:22PM +0800, Qu Wenruo wrote:
>> BTW, there is one important compatibility problem related to all the BGI
>> related features.
>>
>> Although I'm putting the BG_TREE feature as incompatible feature, but in
>> theory, it shou
On Tue, Oct 22, 2019 at 02:30:22PM +0800, Qu Wenruo wrote:
> BTW, there is one important compatibility problem related to all the BGI
> related features.
>
> Although I'm putting the BG_TREE feature as incompatible feature, but in
> theory, it should be RO compatible.
It could be RO compatible ye
On Tue, Oct 22, 2019 at 09:33:06AM +0200, Johannes Thumshirn wrote:
> On 21/10/2019 17:22, David Sterba wrote:
> > --force was added for a different reason, to allow check on a mounted
> > filesystem. I don't think that combining --repair and --force just to
> > allow repair is a good idea. There's
On Tue, 2019-10-22 at 10:01 +0300, Nikolay Borisov wrote:
>
> On 22.10.19 г. 9:59 ч., Nikolay Borisov wrote:
> >
> >
> > On 22.10.19 г. 5:02 ч., Marcos Paulo de Souza wrote:
> >> From: Marcos Paulo de Souza
> >>
> >> When compiling with clang, this warning is shown:
> >>
> >> common/utils.c:404
On Tue, Oct 22, 2019 at 1:33 PM Roman Mamedov wrote:
>
> On Tue, 22 Oct 2019 11:00:07 +0200
> Chris Murphy wrote:
>
> > Hi,
> >
> > So XFS has these
> >
> > [49621.415203] XFS (loop0): Mounting V5 Filesystem
> > [49621.58] XFS (loop0): Ending clean mount
> > ...
> > [49621.58] XFS (loop0)
On Tue, Oct 22, 2019 at 09:54:41AM +0800, Anand Jain wrote:
> >> 1.
> >> The sub-commands as in [2] uses multi-level compile time verbose option,
> >> such as %g_verbose = 0 (quite), %g_verbose = 1 (default), %g_verbose > 1
> >> (real-verbose). And verbose at default is also part the .out files in
On Tue, 22 Oct 2019 11:00:07 +0200
Chris Murphy wrote:
> Hi,
>
> So XFS has these
>
> [49621.415203] XFS (loop0): Mounting V5 Filesystem
> [49621.58] XFS (loop0): Ending clean mount
> ...
> [49621.58] XFS (loop0): Ending clean mount
> [49641.459463] XFS (loop0): Unmounting Filesystem
>
On Tue, Oct 22, 2019 at 12:53:29PM +0300, Nikolay Borisov wrote:
>
>
> On 17.10.19 г. 22:39 ч., David Sterba wrote:
> > Signed-off-by: David Sterba
> > ---
> > fs/btrfs/locking.c | 110 +++--
> > 1 file changed, 96 insertions(+), 14 deletions(-)
> >
> >
On 10/22/19 5:55 PM, Anand Jain wrote:
I agree, I sent patches for it in 2017.
VFS version.
https://patchwork.kernel.org/patch/9745295/
btrfs version:
https://patchwork.kernel.org/patch/9745295/
David, I mean, do you think I should revive the above btrfs patch?
Thanks, Anand
On Tue, Oct 22, 2019 at 11:56 AM Anand Jain wrote:
>
>
> I agree, I sent patches for it in 2017.
>
> VFS version.
> https://patchwork.kernel.org/patch/9745295/
>
> btrfs version:
> https://patchwork.kernel.org/patch/9745295/
>
> There wasn't response on btrfs-v2-patch.
>
> This i
On 2019/10/22 下午5:47, Tobias Reinhard wrote:
> Hi,
>
>
> I noticed that if you punch a hole in the middle of a file the available
> filesystem space seems not to increase.
>
> Kernel is 5.2.11
>
> To reproduce:
>
> ->mkfs.btrfs /dev/loop1 -f
>
> btrfs-progs v4.15.1
> See http://btrfs.wiki.k
(resending to list, I don't know why but I messed up the reply
directly to Nikolay)
On Tue, Oct 22, 2019 at 11:16 AM Nikolay Borisov wrote:
>
> On 22.10.19 =D0=B3. 12:00 =D1=87., Chris Murphy wrote:
> > Hi,
> >
> > So XFS has these
> >
> > [49621.415203] XFS (loop0): Mounting V5 Filesystem
> > [4
I agree, I sent patches for it in 2017.
VFS version.
https://patchwork.kernel.org/patch/9745295/
btrfs version:
https://patchwork.kernel.org/patch/9745295/
There wasn't response on btrfs-v2-patch.
This is not the first time that I am writing patches ahead of
users asking for it,
On 17.10.19 г. 22:39 ч., David Sterba wrote:
> Signed-off-by: David Sterba
> ---
> fs/btrfs/locking.c | 110 +++--
> 1 file changed, 96 insertions(+), 14 deletions(-)
>
> diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c
> index e0e0430577aa..2a0e828
Hi,
I noticed that if you punch a hole in the middle of a file the available
filesystem space seems not to increase.
Kernel is 5.2.11
To reproduce:
->mkfs.btrfs /dev/loop1 -f
btrfs-progs v4.15.1
See http://btrfs.wiki.kernel.org for more information.
Detected a SSD, turning off metadata du
Test if btrfs.ko sucessfully identifies and reports the missing device,
if the missed device contians no btrfs magic string.
Signed-off-by: Anand Jain
---
v2: Comments added to list kernel patch required to pass the test case
Fix copy and paste error in the comment
tests/btrfs/198 | 79
Test if btrfs.ko sucessfully identifies and reports the missing device,
if the missed device contians someother btrfs.
Signed-off-by: Anand Jain
---
v2: Comments updated with the required kernel patch to pass this test.
Use spare device instead of test_mnt to create an alien btrfs device.
On 10/18/19 5:13 PM, Eryu Guan wrote:
On Mon, Oct 07, 2019 at 05:41:01PM +0800, Anand Jain wrote:
Test if btrfs.ko sucessfully identifies and reports the missing device,
if the missed device contians no btrfs magic string.
Signed-off-by: Anand Jain
---
tests/btrfs/197 | 79 +++
On 10/18/19 5:10 PM, Eryu Guan wrote:
On Mon, Oct 07, 2019 at 05:41:00PM +0800, Anand Jain wrote:
Test if btrfs.ko sucessfully identifies and reports the missing device,
if the missed device contians someother btrfs.
Signed-off-by: Anand Jain
---
tests/btrfs/196 | 77 +
On 2019/10/22 下午5:09, Amir Goldstein wrote:
> On Tue, Oct 22, 2019 at 11:00 AM Qu Wenruo wrote:
>>
>> There is a fs corruption report of a tree block in use get trimmed, and
>> cause fs corruption.
>>
>> Although I haven't found the cause from the source code, it won't hurt
>> to add such test c
On 22.10.19 г. 12:00 ч., Chris Murphy wrote:
> Hi,
>
> So XFS has these
>
> [49621.415203] XFS (loop0): Mounting V5 Filesystem
> [49621.58] XFS (loop0): Ending clean mount
> ...
> [49621.58] XFS (loop0): Ending clean mount
> [49641.459463] XFS (loop0): Unmounting Filesystem
>
> It see
On Tue, Oct 22, 2019 at 11:00 AM Qu Wenruo wrote:
>
> There is a fs corruption report of a tree block in use get trimmed, and
> cause fs corruption.
>
> Although I haven't found the cause from the source code, it won't hurt
> to add such test case.
>
> The test case is limited to btrfs due to the
Hi,
So XFS has these
[49621.415203] XFS (loop0): Mounting V5 Filesystem
[49621.58] XFS (loop0): Ending clean mount
...
[49621.58] XFS (loop0): Ending clean mount
[49641.459463] XFS (loop0): Unmounting Filesystem
It seems to me linguistically those last two should be reversed, but whateve
Despite the existing |fua|flush checkpoint, add a new discard
check point to make sure discard is not screwing up things.
Signed-off-by: Qu Wenruo
---
src/log-writes/replay-log.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/log-writes/replay-log.c b/src/log-
Just to make sure the fstrim is not trimming anything vital (like tree
blocks still in use) on btrfs.
The first patch is to enhance log-writes to check each DISCARD
operation.
The feature is not used in test cases, as it's too time consuming.
But should be a pretty handy feature for small logwrite
There is a fs corruption report of a tree block in use get trimmed, and
cause fs corruption.
Although I haven't found the cause from the source code, it won't hurt
to add such test case.
The test case is limited to btrfs due to the replay-log --check|--fsck
hack to reduce runtime.
Other fs can't
On 22.10.19 г. 10:37 ч., Qu Wenruo wrote:
>
>
> On 2019/10/22 下午3:33, Johannes Thumshirn wrote:
>> On 21/10/2019 17:22, David Sterba wrote:
>>> --force was added for a different reason, to allow check on a mounted
>>> filesystem. I don't think that combining --repair and --force just to
>>> al
On 22/10/2019 09:37, Qu Wenruo wrote:
> +1 for '--yes', at least e2fsck has a similar '-y' option.
OK, for me as well. And yes being in line with e2fsck has it's benefits
as well.
Byte,
Johannes
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de
On 2019/10/22 下午3:33, Johannes Thumshirn wrote:
> On 21/10/2019 17:22, David Sterba wrote:
>> --force was added for a different reason, to allow check on a mounted
>> filesystem. I don't think that combining --repair and --force just to
>> allow repair is a good idea. There's a 'dangerous repair
On 21/10/2019 17:22, David Sterba wrote:
> --force was added for a different reason, to allow check on a mounted
> filesystem. I don't think that combining --repair and --force just to
> allow repair is a good idea. There's a 'dangerous repair' mode for eg.
> xfs that allows to do live surgery on a
On 22.10.19 г. 9:59 ч., Nikolay Borisov wrote:
>
>
> On 22.10.19 г. 5:02 ч., Marcos Paulo de Souza wrote:
>> From: Marcos Paulo de Souza
>>
>> When compiling with clang, this warning is shown:
>>
>> common/utils.c:404:3: warning: declaration does not declare anything
>> [-Wmissing-declaratio
On 22.10.19 г. 5:02 ч., Marcos Paulo de Souza wrote:
> From: Marcos Paulo de Souza
>
> When compiling with clang, this warning is shown:
>
> common/utils.c:404:3: warning: declaration does not declare anything
> [-Wmissing-declarations]
> __attribute__ ((fallthrough));
>
> T
45 matches
Mail list logo
