On Mon, May 20, 2019 at 2:35 PM Patrik Lundquist
wrote:
>
> On Mon, 20 May 2019 at 14:40, David Disseldorp wrote:
> >
> > On Mon, 20 May 2019 14:14:48 +0200, Patrik Lundquist wrote:
> >
> > > On Mon, 20 May 2019 at 13:58, Austin S. Hemmelgarn
> > > wrote:
> > > >
> > > > On 2019-05-20 07:15, Ne
On Mon, 20 May 2019 at 14:40, David Disseldorp wrote:
>
> On Mon, 20 May 2019 14:14:48 +0200, Patrik Lundquist wrote:
>
> > On Mon, 20 May 2019 at 13:58, Austin S. Hemmelgarn
> > wrote:
> > >
> > > On 2019-05-20 07:15, Newbugreport wrote:
> > > > Patrik, thank you. I've enabled the SAMBA module,
btrfs-progs: btrfs_scan_kernel(): btrfs killed by SIGABRT
https://bugzilla.redhat.com/show_bug.cgi?id=1711787
btrfs-progs-4.20.2-1.fc29
kernel:5.0.16-200.fc29.x86_64
If I understand the bug report correctly, one shell is watching for
changing 'btrfs fi show' while another deletes a device, and th
Hello,
If you want to do this (subvolumes/submounts) I think
you should get familiar with the:
sorry, that's well beyond my skill-set. Honestly, I fear I cannot do any
good solving this issue.
My intent is/was to make you aware -although frankly, for *me* this is
no problem.
Greetings,
Hendr
Hello,
You posted this:
I am using Openmediavault (debian based NAS distribution), which is not
actively supporting btrfs
It is this that I was referring to.
Ah, yes.
OMV intended to move to btrfs as the only choice with the next version. In
order to pave the way, I intended to be an early ad
On Mon, May 20, 2019 at 05:54:13PM +, Hendrik Friedel via samba wrote:
> Hello,
>
> > Is btrfs becoming more common ?
> In my impression: Yes. Also, this problem seems to affect also zfs and thus
> all (?) file systems that support checksums and scrubbing in linux;
> consequently all filesyste
-- Weitergeleitete Nachricht --
Von: "Hendrik Friedel"
An: "Rowland penny" ; "sambalist"
; "Btrfs BTRFS"
Gesendet: 20.05.2019 19:54:13
Betreff: Re[2]: [Samba] Fw: Btrfs Samba and Quotas
Hello,
Is btrfs becoming more common ?
In my impression: Yes. Also, this problem seems to affe
The pull request you sent on Mon, 20 May 2019 18:52:43 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.2-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f49aa1de98363b6c5fba4637678d6b0ba3d18065
Thank you!
--
Deet-doot-dot, I am a
Hi,
the branch contains fixes, notable hilights:
* fixes for some long-standing bugs in fsync that were quite hard to
catch but now finaly fixed
* some fixups to error handling paths that did not properly clean up
(locking, memory)
* fix to space reservation for inheriting properties
No me
On Sun, May 19, 2019 at 11:25:19AM +0100, Filipe Manana wrote:
> On Sun, May 19, 2019 at 12:50 AM Zygo Blaxell
> wrote:
> > [ 6232.433929][ T4605] RIP: 0010:btrfs_reloc_pre_snapshot+0x24/0x50
>
> Known problem, should be fixed by:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torva
On Mon, May 20, 2019 at 10:13 AM Nikolay Borisov wrote:
>
>
>
> On 20.05.19 г. 12:10 ч., Filipe Manana wrote:
> > On Mon, May 20, 2019 at 9:23 AM Nikolay Borisov wrote:
> >>
> >>
> >>
> >> On 20.05.19 г. 11:11 ч., Nikolay Borisov wrote:
> >>> This patch removes stray smp_mb before root->log_root
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 16e7549f045d Btrfs: incompatible format change to remove hole
extents.
The bot has tested the following trees: v5.1.3, v5.0.17, v4.19.44, v4.14.120,
v4.9.177, v4.4.180, v3.18.140.
On Mon, 20 May 2019 14:14:48 +0200, Patrik Lundquist wrote:
> On Mon, 20 May 2019 at 13:58, Austin S. Hemmelgarn
> wrote:
> >
> > On 2019-05-20 07:15, Newbugreport wrote:
> > > Patrik, thank you. I've enabled the SAMBA module, which may help in the
> > > future. Does the GUI file manager (i.e
On Mon, 20 May 2019 at 13:58, Austin S. Hemmelgarn wrote:
>
> On 2019-05-20 07:15, Newbugreport wrote:
> > Patrik, thank you. I've enabled the SAMBA module, which may help in the
> > future. Does the GUI file manager (i.e. Nautilus) need special support?
> It shouldn't (Windows' default file mana
On 2019-05-20 07:15, Newbugreport wrote:
Patrik, thank you. I've enabled the SAMBA module, which may help in the future.
Does the GUI file manager (i.e. Nautilus) need special support?
It shouldn't (Windows' default file manager doesn't, and most stuff on
Linux uses Samba so it shouldn't either
On Mon, May 20, 2019 at 07:34:34AM -0400, Austin S. Hemmelgarn wrote:
> Those would also be cryptographic applications, which BTRFS is not. If
> you're in one of those situations and need to have cryptographic
> verification of files on the system, you need to be using either IMA,
> dm-verity, or
On 2019-05-17 14:36, Diego Calleja wrote:
El miércoles, 15 de mayo de 2019 19:27:21 (CEST) David Sterba escribió:
Once the code is ready for more checksum algos, we'll pick candidates
and my idea is to select 1 fast (not necessarily strong, but better
than crc32c) and 1 strong (but slow, and sha
On 2019-05-20 03:47, Johannes Thumshirn wrote:
On Sat, May 18, 2019 at 02:38:08AM +0200, Adam Borowski wrote:
On Fri, May 17, 2019 at 09:07:03PM +0200, Johannes Thumshirn wrote:
On Fri, May 17, 2019 at 08:36:23PM +0200, Diego Calleja wrote:
If btrfs needs an algorithm with good performance/sec
Hi,
On Sat, May 18, 2019 at 04:06:40AM +, Robert White wrote:
> For several reasons it would be really convenient if there was a way to
> mark a btrfs directory such that the directories created in the marked
> directory would actually be automatically converted to subvolume
> creation and
Patrik, thank you. I've enabled the SAMBA module, which may help in the future.
Does the GUI file manager (i.e. Nautilus) need special support?
Andrea, thank you for the link. bup is impressive but does it work well with
btrfs snapshots? My live drive contains the main volume alongside many
sna
On Mon, 20 May 2019 at 02:36, Andrei Borzenkov wrote:
>
> 19.05.2019 11:11, Newbugreport пишет:
> > I have 3-4 years worth of snapshots I use for backup purposes. I keep
> > R-O live snapshots, two local backups, and AWS Glacier Deep Freeze. I
> > use both send | receive and send > file. This work
On Sun, 19 May 2019 23:06:25 +0300, Andrei Borzenkov wrote:
> 19.05.2019 11:11, Newbugreport пишет:
> > I have 3-4 years worth of snapshots I use for backup purposes. I keep
> > R-O live snapshots, two local backups, and AWS Glacier Deep Freeze. I
> > use both send | receive and send > file. This
On 20.05.19 г. 12:10 ч., Filipe Manana wrote:
> On Mon, May 20, 2019 at 9:23 AM Nikolay Borisov wrote:
>>
>>
>>
>> On 20.05.19 г. 11:11 ч., Nikolay Borisov wrote:
>>> This patch removes stray smp_mb before root->log_root from
>>> join_running_log_trans
>>> as well as the unlocked check for roo
On Mon, May 20, 2019 at 9:23 AM Nikolay Borisov wrote:
>
>
>
> On 20.05.19 г. 11:11 ч., Nikolay Borisov wrote:
> > This patch removes stray smp_mb before root->log_root from
> > join_running_log_trans
> > as well as the unlocked check for root->log_root. log_root is only set in
> > btrfs_add_log_
From: Filipe Manana
Test that an incremental send receive does not issue clone operations
that attempt to clone the last block of a file, with a size not aligned to
the filesystem's sector size, into the middle of some other file. Such
clone request causes the receiver to fail (with EINVAL), for
From: Filipe Manana
When doing an incremental send we can now issue clone operations with a
source range that ends at the source's file eof and with a destination
range that ends at an offset smaller then the destination's file eof.
If the eof of the source file is not aligned to the sector size
From: Filipe Manana
Test that an incremental send with not corrupt data when the source
filesystem has the no-holes feature enabled, a file has prealloc
(unwritten) extents that start after its size and hole is punched (after
the first snapshot is made) that removes all extents from some offset u
From: Filipe Manana
When using the no-holes feature, if we have a file with prealloc extents
with a start offset beyond the file's eof, doing an incremental send can
cause corruption of the file due to incorrect hole detection. Such case
requires that the prealloc extent(s) exist in both the pare
On 20.05.19 г. 11:11 ч., Nikolay Borisov wrote:
> This patch removes stray smp_mb before root->log_root from
> join_running_log_trans
> as well as the unlocked check for root->log_root. log_root is only set in
> btrfs_add_log_tree, called from start_log_trans under root->log_mutex.
> Furthermor
This patch removes stray smp_mb before root->log_root from
join_running_log_trans
as well as the unlocked check for root->log_root. log_root is only set in
btrfs_add_log_tree, called from start_log_trans under root->log_mutex.
Furthermore, log_root is freed in btrfs_free_log, called from commit_fs
On Sat, May 18, 2019 at 02:38:08AM +0200, Adam Borowski wrote:
> On Fri, May 17, 2019 at 09:07:03PM +0200, Johannes Thumshirn wrote:
> > On Fri, May 17, 2019 at 08:36:23PM +0200, Diego Calleja wrote:
> > > If btrfs needs an algorithm with good performance/security ratio, I would
> > > suggest cons
31 matches
Mail list logo
