ssd vs ssd_spread with sdcard or emmc

Hi, I'm not finding any recent advice for sdcard or eMMC media, both of which trigger the ssd mount option automatically. I seem to recall ssd has had some optimizations recently, but haven't heard much about ssd_spread. While sdcard and eMMC are rather different, it seems they have two things

Re: File permissions lost during send/receive?

Marc Joliet posted on Tue, 24 Jul 2018 22:42:06 +0200 as excerpted: > On my system I get: > > % sudo getcap /bin/ping /sbin/unix_chkpwd > /bin/ping = cap_net_raw+ep > /sbin/unix_chkpwd = cap_dac_override+ep > >> (getcap on unix_chkpwd returns nothing, but while I use kde/plasma I >> don't

Re: File permissions lost during send/receive?

Am Dienstag, 24. Juli 2018, 21:46:14 CEST schrieb Duncan: > Andrei Borzenkov posted on Tue, 24 Jul 2018 20:53:15 +0300 as excerpted: > > 24.07.2018 15:16, Marc Joliet пишет: > >> Hi list, > >> > >> (Preemptive note: this was with btrfs-progs 4.15.1, I have since > >> upgraded to 4.17. My kernel

Re: [PATCH resend 1/2] btrfs: allow defrag on a file opened ro that has rw permissions

On Mon, Jul 23, 2018 at 05:26:24PM +0200, David Sterba wrote: > On Wed, Jul 18, 2018 at 12:08:59AM +0200, Adam Borowski wrote: (Combined with as-folded) | | btrfs: allow defrag on a file opened read-only that has rw permissions | | > > Requiring a rw descriptor conflicts both ways with exec,

Re: File permissions lost during send/receive?

Andrei Borzenkov posted on Tue, 24 Jul 2018 20:53:15 +0300 as excerpted: > 24.07.2018 15:16, Marc Joliet пишет: >> Hi list, >> >> (Preemptive note: this was with btrfs-progs 4.15.1, I have since >> upgraded to 4.17. My kernel version is 4.14.52-gentoo.) >> >> I recently had to restore the root

Re: File permissions lost during send/receive?

24.07.2018 15:16, Marc Joliet пишет: > Hi list, > > (Preemptive note: this was with btrfs-progs 4.15.1, I have since upgraded to > 4.17. My kernel version is 4.14.52-gentoo.) > > I recently had to restore the root FS of my desktop from backup (extent tree > corruption; not sure how, possibly

Next btrfs development cycle open - 4.20

From: David Sterba Hi, a friendly reminder of the timetable and what's expected at this phase. Besides the recurring stuff, there's an update about development git repos. 4.17 - current 4.18 - upcoming, urgent regression fixes only 4.19 - development closed, pull request in prep, fixes or

Re: [PATCH v2] Btrfs: fix send failure when root has deleted files still open

On Tue, Jul 24, 2018 at 11:54:04AM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > The more common use case of send involves creating a RO snapshot and then > use it for a send operation. In this case it's not possible to have inodes > in the snapshot that have a link count of zero

File permissions lost during send/receive?

Hi list, (Preemptive note: this was with btrfs-progs 4.15.1, I have since upgraded to 4.17. My kernel version is 4.14.52-gentoo.) I recently had to restore the root FS of my desktop from backup (extent tree corruption; not sure how, possibly a loose SATA cable?). Everything was fine, even

Re: [PATCH 07/22] btrfs: don't leak ret from do_chunk_alloc

On Thu, Jul 19, 2018 at 06:43:39PM +0300, Nikolay Borisov wrote: > > > On 19.07.2018 17:49, Josef Bacik wrote: > > If we're trying to make a data reservation and we have to allocate a > > data chunk we could leak ret == 1, as do_chunk_alloc() will return 1 if > > it allocated a chunk. Since the

Re: [PATCH v2 2/2] btrfs: fix missing superblock update in the device delete commit transaction

On Tue, Jul 24, 2018 at 05:28:03PM +0800, Lu Fengqi wrote: > >I can't reproduce the issue. Do you reproduce consistently? and I > > Sorry I've taken so long to reply. > > There are four virtual machines with the different storage backend here. > And I can reproduce this issue consistently on the

[PATCH v2] Btrfs: fix send failure when root has deleted files still open

From: Filipe Manana The more common use case of send involves creating a RO snapshot and then use it for a send operation. In this case it's not possible to have inodes in the snapshot that have a link count of zero (inode with an orphan item) since during snapshot creation we do the orphan

Re: [PATCH 0/7] fs_info cleanups for volume.c

On Tue, Jul 24, 2018 at 04:59:00PM +0800, Lu Fengqi wrote: > After I applied this patchset, my test also encountered this crash. > However, the result of git bisect shows the cause may be the > "[PATCH 2/2] btrfs: fix missing superblock update in the device delete commit > transaction". >

Re: [PATCH v2 2/2] btrfs: fix missing superblock update in the device delete commit transaction

On Mon, Jul 23, 2018 at 03:52:59PM +0800, Anand Jain wrote: > > >On 07/21/2018 02:01 PM, Lu Fengqi wrote: >> On Tue, Jul 03, 2018 at 05:07:24PM +0800, Anand Jain wrote: >> > When a device is deleted, the btrfs_super_block::number_devices is >> > reduced by 1, but we do that after the commit

Re: [PATCH 0/7] fs_info cleanups for volume.c

On Tue, Jul 24, 2018 at 10:28:04AM +0200, David Sterba wrote: >On Mon, Jul 23, 2018 at 03:25:01PM +0200, David Sterba wrote: >> On Fri, Jul 20, 2018 at 07:37:46PM +0300, Nikolay Borisov wrote: >> > Here are a bunch of patches which cleanup extraneous fs_info parameters to >> > function which

Re: [PATCH 0/7] fs_info cleanups for volume.c

On Mon, Jul 23, 2018 at 03:25:01PM +0200, David Sterba wrote: > On Fri, Jul 20, 2018 at 07:37:46PM +0300, Nikolay Borisov wrote: > > Here are a bunch of patches which cleanup extraneous fs_info parameters to > > function which already take a structure that holds a reference to the > > fs_info.