On Fri, Feb 5, 2021 at 3:55 PM Lennart Poettering
wrote:
>
> On Fr, 05.02.21 20:58, Maksim Fomin (ma...@fomin.one) wrote:
>
> > > You know, we issue the btrfs ioctl, under the assumption that if the
> > > file is already perfectly defragmented it's a NOP. Are you suggesting
> > > it isn't a NOP in
On Fr, 05.02.21 20:58, Maksim Fomin (ma...@fomin.one) wrote:
> > You know, we issue the btrfs ioctl, under the assumption that if the
> > file is already perfectly defragmented it's a NOP. Are you suggesting
> > it isn't a NOP in that case?
>
> So, what is the reason for defragmenting journal is B
On Fr, 05.02.21 16:16, Phillip Susi (ph...@thesusis.net) wrote:
>
> Lennart Poettering writes:
>
> > Nope. We always interleave stuff. We currently open all journal files
> > in parallel. The system one and the per-user ones, the current ones
> > and the archived ones.
>
> Wait... every time you l
Lennart Poettering writes:
> journalctl gives you one long continues log stream, joining everything
> available, archived or not into one big interleaved stream.
If you ask for everything, yes... but if you run journalctl -b then
shuoldn't it only read back until it finds the start of the curre
On Fr, 05.02.21 20:43, Dave Howorth (syst...@howorth.org.uk) wrote:
> 128 MB files, and I might allocate an extra MB or two for overhead, I
> don't know. So when it first starts there'll be 128 MB allocated and
> 384 MB free. In stable state there'll be 512 MB allocated and nothing
> free. One 128
Maksim Fomin writes:
> I would say it depends on whether defragmentation issues are feature
> of btrfs. As Chris mentioned, if root fs is snapshotted,
> 'defragmenting' the journal can actually increase fragmentation. This
> is an example when the problem is caused by a feature (not a bug) in
> b
Dave Howorth writes:
> PS I'm subscribed to the list. I don't need a copy.
FYI, rather than ask others to go out of their way when replying to you,
you should configure your mail client to set the Reply-To: header to
point to the mailing list address so that other people's mail clients do
what
Lennart Poettering writes:
> Nope. We always interleave stuff. We currently open all journal files
> in parallel. The system one and the per-user ones, the current ones
> and the archived ones.
Wait... every time you look at the journal at all, it has to read back
through ALL of the archived jo
‐‐‐ Original Message ‐‐‐
On Friday, February 5, 2021 3:23 PM, Lennart Poettering
wrote:
> On Do, 04.02.21 12:51, Chris Murphy (li...@colorremedies.com) wrote:
>
> > On Thu, Feb 4, 2021 at 6:49 AM Lennart Poettering
> > lenn...@poettering.net wrote:
> >
> > > You want to optimize write pa
On Fri, 5 Feb 2021 17:44:14 +0100
Lennart Poettering wrote:
> On Fr, 05.02.21 16:06, Dave Howorth (syst...@howorth.org.uk) wrote:
>
> > On Fri, 5 Feb 2021 16:23:02 +0100
> > Lennart Poettering wrote:
> > > I don't think that makes much sense: we rotate and start new
> > > files for a multitude
On Fr, 05.02.21 16:06, Dave Howorth (syst...@howorth.org.uk) wrote:
> On Fri, 5 Feb 2021 16:23:02 +0100
> Lennart Poettering wrote:
> > I don't think that makes much sense: we rotate and start new files for
> > a multitude of reasons, such as size overrun, time jumps, abnormal
> > shutdown and so
On Fri, 5 Feb 2021 16:23:02 +0100
Lennart Poettering wrote:
> I don't think that makes much sense: we rotate and start new files for
> a multitude of reasons, such as size overrun, time jumps, abnormal
> shutdown and so on. If we'd always leave a fully allocated file around
> people would hate us.
On Fr, 05.02.21 10:24, Phillip Susi (ph...@thesusis.net) wrote:
>
> Lennart Poettering writes:
>
> > You are focussing only on the one-time iops generated during archival,
> > and are ignoring the extra latency during access that fragmented files
> > cost. Show me that the iops reduction during th
Lennart Poettering writes:
> You are focussing only on the one-time iops generated during archival,
> and are ignoring the extra latency during access that fragmented files
> cost. Show me that the iops reduction during the one-time operation
> matters and the extra latency during access doesn't
Chris Murphy writes:
> But it gets worse. The way systemd-journald is submitting the journals
> for defragmentation is making them more fragmented than just leaving
> them alone.
Wait, doesn't it just create a new file, fallocate the whole thing, copy
the contents, and delete the original? How
On Do, 04.02.21 12:51, Chris Murphy (li...@colorremedies.com) wrote:
> On Thu, Feb 4, 2021 at 6:49 AM Lennart Poettering
> wrote:
>
> > You want to optimize write pattersn I understand, i.e. minimize
> > iops. Hence start with profiling iops, i.e. what defrag actually costs
> > and then weight th
On Thu, 2021-02-04 at 22:16 +0300, Andrei Borzenkov wrote:
> 03.02.2021 22:25, Benjamin Berg пишет:
> > Requires= actually has the difference that the unit must become
> > part of
> > the transaction (if it is not active already). So you get a hard
> > failure and appropriate logging if the unit ca
17 matches
Mail list logo