lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD+ocbzhhgpdVdMU6TDMAppjuJkD3P_Tnq=5rdaQpr7+Q1DNDw@mail.gmail.com>
Date:   Wed, 9 Dec 2020 21:24:37 -0800
From:   harshad shirwadkar <harshadshirwadkar@...il.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 05/15] mke2fs, tune2fs: update man page with fast commit info

On Wed, Dec 2, 2020 at 10:33 AM Theodore Y. Ts'o <tytso@....edu> wrote:
>
> On Fri, Nov 20, 2020 at 11:15:56AM -0800, Harshad Shirwadkar wrote:
> > This patch adds information about fast commit feature in mke2fs and
> > tune2fs man pages.
> >
> > Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@...il.com>
>
> So this is a bit more of a personal preference thing, but I like to
> keep the libext2fs changes from the changes to the userspace
> applications, and then combine the changes to the userspace progams
> (mke2fs and tune2fs in this case) with the man page updates.
>
> So you might want to consider moving the mke2fs and tune2fs changes
> from the previous patch and then combining them with this patch, and
> adjusting the commit message appropriately?
Sounds good, will do that.
>
> > diff --git a/misc/mke2fs.8.in b/misc/mke2fs.8.in
> > index e6bfc6d6..2833b408 100644
> > --- a/misc/mke2fs.8.in
> > +++ b/misc/mke2fs.8.in
> > @@ -521,6 +521,27 @@ The size of the journal must be at least 1024 filesystem blocks
> >  and may be no more than 10,240,000 filesystem blocks or half the total
> >  file system size (whichever is smaller)
> >  .TP
> > +.BI fast_commit_size= fast-commit-size
> > +Create an additional fast commit journal area of size
> > +.I fast-commit-size
> > +kilobytes.
> > +This option is only valid if
> > +.B fast_commit
> > +feature is enabled
> > +on the file system. If this option is not specified and if
> > +.B fast_commit
> > +feature is turned on, fast commit area size defaults to
> > +.I journal-size
> > +/ 64 megabytes. The total size of the journal with
> > +.B fast_commit
> > +feature set is
> > +.I journal-size
> > ++ (
> > +.I fast-commit-size
> > +* 1024) megabytes. The total journal size may be no more than
> > +10,240,000 filesystem blocks or half the total file system size
> > +(whichever is smaller).
> > +.TP
>
> So as I recall, aren't we currently calculating the fast commit size
> as a fraction of the total journal size?  I'm not sure this is in sync
> with was in the last patch.
So there are following three cases of journal area configuration:

1) User provides fast commit size and journal size as arguments to mke2fs
2) We are using internal journal and user asks mke2fs to calculate
journal size by default
3) We are using external journal and user asks mke2fs to calculate
journal size by default

So, for (1), we just provide an option "fast-commit-size" which is an
added area on top of the normal journal area. That's why total journal
size becomes the normal journal size + fast commit area size. However,
things become tricky for option (2) and (3). For (2), I'm *adding*
1/64th of the total journal area as a fast commit area on top of
existing journal. So, with fast commits enabled, the default total
journal size becomes 65/64 times the journal default journal area that
would have been created by mke2fs before these changes. For (3)
however, we don't have an option to use above logic since the external
device size is fixed. So, we have to divide the total journal area
into two parts. We split the external journal as 1:64 (fast commit :
normal commit).

Does this make sense?

Thanks,
Harshad
>
>                                         - Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ