Austin S. Hemmelgarn - 17.08.18, 14:55:
> On 2018-08-17 08:28, Martin Steigerwald wrote:
> > Thanks for your detailed answer.
> >
> > Austin S. Hemmelgarn - 17.08.18, 13:58:
> >> On 2018-08-17 05:08, Martin Steigerwald wrote:
[…]
> >>> Anyway, creating a new filesystem may have been better here
>
Hi Roman.
Now with proper CC.
Roman Mamedov - 17.08.18, 14:50:
> On Fri, 17 Aug 2018 14:28:25 +0200
>
> Martin Steigerwald wrote:
> > > First off, keep in mind that the SSD firmware doing compression
> > > only
> > > really helps with wear-leveling. Doing it in the filesystem will
> > > help n
Austin S. Hemmelgarn - 17.08.18, 15:01:
> On 2018-08-17 08:50, Roman Mamedov wrote:
> > On Fri, 17 Aug 2018 14:28:25 +0200
> >
> > Martin Steigerwald wrote:
> >>> First off, keep in mind that the SSD firmware doing compression
> >>> only
> >>> really helps with wear-leveling. Doing it in the fil
Hi,
after growing a single btrfs file system (on a loop device, with btrfs
fi resize max /fs ) it hangs later (sometimes much later). Symptoms:
* A unkillable btrfs process using 100% (of one) CPU in R state (no
kernel trace, cannot attach with strace, gdb or run linux perf)
* Other processes wit
On Mon, Aug 06, 2018 at 06:12:37PM +0800, Anand Jain wrote:
> test case btrfs/164 reported UAF..
>
> [ 6712.084324] general protection fault: [#1] PREEMPT SMP
> ::
> [ 6712.195423] btrfs_update_commit_device_size+0x75/0xf0 [btrfs]
> [ 6712.201424] btrfs_commit_transaction+0x57d/0xa90 [btrfs
On Sat, Aug 04, 2018 at 09:10:56PM +0800, Lu Fengqi wrote:
> Since ret must be 0 here, don't have to return separately in advance.
>
> No functional change.
>
> Signed-off-by: Lu Fengqi
Added to misc-next too, the change is fairly trivial so I was pondering
about code readability impacts, but i
On Thu, Aug 09, 2018 at 09:46:04AM +0800, Lu Fengqi wrote:
> After btrfs_qgroup_reserve_meta_prealloc(), num_bytes will be assigned
> again by btrfs_calc_trans_metadata_size(). Once block_rsv fails, we can't
> properly free the num_bytes of the previous qgroup_reserve. Use a separate
> variable to
On 2018-08-17 08:50, Roman Mamedov wrote:
On Fri, 17 Aug 2018 14:28:25 +0200
Martin Steigerwald wrote:
First off, keep in mind that the SSD firmware doing compression only
really helps with wear-leveling. Doing it in the filesystem will help
not only with that, but will also give you more spa
On 2018-08-17 08:28, Martin Steigerwald wrote:
Thanks for your detailed answer.
Austin S. Hemmelgarn - 17.08.18, 13:58:
On 2018-08-17 05:08, Martin Steigerwald wrote:
[…]
I have seen a discussion about the limitation in point 2. That
allowing to add a device and make it into RAID 1 again migh
On Fri, 17 Aug 2018 14:28:25 +0200
Martin Steigerwald wrote:
> > First off, keep in mind that the SSD firmware doing compression only
> > really helps with wear-leveling. Doing it in the filesystem will help
> > not only with that, but will also give you more space to work with.
>
> While also
Thanks for your detailed answer.
Austin S. Hemmelgarn - 17.08.18, 13:58:
> On 2018-08-17 05:08, Martin Steigerwald wrote:
[…]
> > I have seen a discussion about the limitation in point 2. That
> > allowing to add a device and make it into RAID 1 again might be
> > dangerous, cause of system chun
On Fri, Aug 17, 2018 at 05:05:28AM +0800, Liu Bo wrote:
> @path is always NULL when it comes to the if branch.
>
> Signed-off-by: Liu Bo
Reviewed-by: David Sterba
On 2018-08-17 05:08, Martin Steigerwald wrote:
Hi!
This happened about two weeks ago. I already dealt with it and all is
well.
Linux hung on suspend so I switched off this ThinkPad T520 forcefully.
After that it did not boot the operating system anymore. Intel SSD 320,
latest firmware, which sh
Hi!
This happened about two weeks ago. I already dealt with it and all is
well.
Linux hung on suspend so I switched off this ThinkPad T520 forcefully.
After that it did not boot the operating system anymore. Intel SSD 320,
latest firmware, which should patch this bug, but apparently does not,
From: Filipe Manana
Test that deduplication of an entire file that has a size that is not
aligned to the filesystem's block size into a different file does not
corrupt the destination's file data.
This test is motivated by a bug found in Btrfs which is fixed by the
following patch for the linux
From: Filipe Manana
If we deduplicate extents between two different files we can end up
corrupting data if the source range ends at the size of the source file,
the source file's size is not aligned to the filesystem's block size
and the destination range does not go past the size of the destinat
Ok, but I cannot guarantee that I don't need to cancel scrub during the process
As said, this is a domestic storage, and when scrub is running the
performance hit is big enough to prevent smooth streaming of HD and 4k
movies
Il giorno gio 16 ago 2018 alle ore 21:38 ha scritto:
>
> Could you show s
On 17.08.2018 00:07, Liu Bo wrote:
> Btrfs's btree locking has two modes, spinning mode and blocking mode,
> while searching btree, locking is always acquired in spinning mode and
> then converted to blocking mode if necessary, and in some hot paths we may
> switch the locking back to spinning m
18 matches
Mail list logo
