On 25.06.19 г. 5:49 ч., Chris Murphy wrote:
> False alarm, not a new issue at all!
>
> I have a different system on kernel 5.1.11 using Btrfs as root with
> persistent systemd-journald storage, and compress=zstd. And I never
> have problems with it, so I never run btrfs check on it, until now.
On Mon, Jun 24, 2019 at 02:58:17PM -0700, Darrick J. Wong wrote:
> On Mon, Jun 24, 2019 at 01:37:37PM +0200, Jan Kara wrote:
> > On Fri 21-06-19 16:57:07, Darrick J. Wong wrote:
> > > From: Darrick J. Wong
> > >
> > > When we're using FS_IOC_SETFLAGS to set the immutable flag on a file, we
> > >
False alarm, not a new issue at all!
I have a different system on kernel 5.1.11 using Btrfs as root with
persistent systemd-journald storage, and compress=zstd. And I never
have problems with it, so I never run btrfs check on it, until now.
And yep, same problem. All the journals that have been ro
On Mon, Jun 24, 2019 at 7:01 PM Chris Murphy wrote:
>
> Anyway the problem looks minor, the file system itself is fine. But it
> does stop the startup process.
Aa! I was on "autopilot" and made the root read-only. And that's
why the startup fails. It has nothing to do with the compressed noco
On Mon, Jun 24, 2019 at 5:48 PM Qu Wenruo wrote:
>
> The problem is not complex, one inode which shouldn't go through
> compression (maybe nodatacow or nodatasum set) has go through compression.
>
> This leads to missing csum while still compressed.
>
> This could cause read time error.
>
> The so
On Mon, Jun 24, 2019 at 5:29 PM Holger Hoffstätte
wrote:
>
> On 6/25/19 12:46 AM, Chris Murphy wrote:
> > Same call trace on ro mount and ro scrub with 5.2.0-rc2+, but also an
> > additional call trace related to zstd. As this is a zstd compressed
> > file system, it might be related.
> >
> > [ 3
On 2019/6/25 上午5:19, Chris Murphy wrote:
> Short version:
> sysroot is Btrfs. I made a rw snapshot of an ro snapshot in order to
> do a rollback, and then rebooted. The umount was clean, but during
> startup I noticed many services had failed, but couldn't tell why and
> I had no shell or remote
On 6/25/19 12:46 AM, Chris Murphy wrote:
Same call trace on ro mount and ro scrub with 5.2.0-rc2+, but also an
additional call trace related to zstd. As this is a zstd compressed
file system, it might be related.
[ 366.319583]
[ 366.325036] WARNING: inconsisten
Same call trace on ro mount and ro scrub with 5.2.0-rc2+, but also an
additional call trace related to zstd. As this is a zstd compressed
file system, it might be related.
[ 366.319583]
[ 366.325036] WARNING: inconsistent lock state
[ 366.330615] 5.2.0-0.rc2.git
This is with kernel 5.0.7, still ro mounted with blockdev --setro as well
[root@localhost-live ~]# btrfs scrub start -BrR /mnt
scrub done for 72df6d5b-26d1-47ff-a9ab-33f6a0b2c4cf
scrub started at Mon Jun 24 17:59:57 2019 and finished after 00:00:15
data_extents_scrubbed: 231002
tree_ex
On Mon, Jun 24, 2019 at 01:37:37PM +0200, Jan Kara wrote:
> On Fri 21-06-19 16:57:07, Darrick J. Wong wrote:
> > From: Darrick J. Wong
> >
> > When we're using FS_IOC_SETFLAGS to set the immutable flag on a file, we
> > need to ensure that userspace can't continue to write the file after the
> >
Short version:
sysroot is Btrfs. I made a rw snapshot of an ro snapshot in order to
do a rollback, and then rebooted. The umount was clean, but during
startup I noticed many services had failed, but couldn't tell why and
I had no shell or remote service to get into the system. I don't know
if a rw
On Sun, Jun 23, 2019 at 7:23 AM Robert wrote:
>
> root@Dyskietka:~# uname -a
> Linux Dyskietka 4.4.116.armada.1 #1 SMP Mon Feb 19 22:05:00 PST 2018
> armv7l GNU/Linux
> root@Dyskietka:~# btrfs --version
> btrfs-progs v4.12
Old kernel, old progs. Definitely do not use 'btrfs check --repair'
On Sun, Jun 23, 2019 at 7:52 PM Qu Wenruo wrote:
>
>
>
> On 2019/6/24 上午4:45, Zygo Blaxell wrote:
> > I first observed these correlations back in 2016. We had a lot of WD
> > Green and Black drives in service at the time--too many to replace or
> > upgrade them all early--so I looked for a workar
On Mon, Jun 24, 2019 at 05:33:58PM +0200, Jan Kara wrote:
> On Fri 21-06-19 16:57:07, Darrick J. Wong wrote:
> > +/*
> > + * Flush file data before changing attributes. Caller must hold any locks
> > + * required to prevent further writes to this file until we're done setting
> > + * flags.
> > +
On Fri 21-06-19 16:57:07, Darrick J. Wong wrote:
> +/*
> + * Flush file data before changing attributes. Caller must hold any locks
> + * required to prevent further writes to this file until we're done setting
> + * flags.
> + */
> +static inline int inode_flush_data(struct inode *inode)
> +{
> +
On Fri 21-06-19 16:57:07, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> When we're using FS_IOC_SETFLAGS to set the immutable flag on a file, we
> need to ensure that userspace can't continue to write the file after the
> file becomes immutable. To make that happen, we have to flush all the
On Mon, Jun 24, 2019 at 10:01:31AM +, Martin Raiber wrote:
> I've fixed the same problem(s) by increasing the global metadata size as
> well. Though I haven't encountered them since Josef Bacik's block rsv
> rework in 5.0.
Now _that_ is interesting--for me, this issue never happened in five
ye
On Fri 21-06-19 16:56:58, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
> metadata can
I've fixed the same problem(s) by increasing the global metadata size as
well. Though I haven't encountered them since Josef Bacik's block rsv
rework in 5.0.
Another problem with increasing the global metadata size is, that I
think it is the only way dirty metadata is throttled. If increased too
mu
xfs will need to be updated to fill in the additional iomap for the
COW case. Has this series been tested on xfs?
I can't say I'm a huge fan of this two iomaps in one method call
approach. I always though two separate iomap iterations would be nicer,
but compared to that even the older hack with
On Fri, Jun 21, 2019 at 02:28:25PM -0500, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> btrfs uses page->private as well to store extent_buffer. Make
> the check stricter to make sure we are using page->private for iop by
> comparing iblocksize < PAGE_SIZE.
>
> Signed-off-by: Goldwyn Ro
22 matches
Mail list logo
