Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
Am 01.10.2013 12:30, schrieb Zbigniew Jędrzejewski-Szmek: >> Now, according to the fstab(5) manpage, the root fs should have passno 1 >> and everything else should have passno 2. We could ensure the same >> behaviour by having After=systemd-root-fsck.service in >> systemd-fsck@.service. > Serializing fscks like that makes only limited sense if you're doing > it from the initrd. But if the fsck is run from the ro root, then yes, > I guess you want to make sure that the fs that holds the fsck binaries > is OK before continuing. That's why systemd-root-fsck.service should be ordered before all systemd-fsck@.service units. This only affects the non-initrd case. In the initrd case, systemd-root-fsck should not be run anyway and the ordering I suggested has no effect. > Manual ordering is a bit of a corner case, but like Jan Engelhart wrote... >> On an iSCSI server, export /dev/sdf1 and /dev/sdf2 as separate LUNs. >> The iSCSI client will import them as /dev/sda and /dev/sdb. That is a >> case where, if you can, you would specify FsckPassNo because the >> automatic detection likely stops at host boundaries. > ...there might be use cases. Even if we drop support for ordering by > fsck-no field in /etc/fstab, do we have a new way of configuring this > through /etc/fstab? (Something like > x-systemd.comment=After=systemd-fsck-var.service ?) > Or is this really too much of an edge case? I don't think that the current > fsck-no-related code is harmful in any way or a maintenance burden, so > if it is dropped, it would be nice to cover all bases. If we are to keep the strict fs_passno as documented in fstab(5), I suggest we go with Lennart's suggestion: > d) Pimp up fstab-generator to write only .d dropins that add the >necessary deps between the fsck instances, but nothing else. I find the whole concept of the FsckPassNo option disturbing (including its documentation). It introduces an additional directive for something that can be solved with the existing ones, with the comment that it should only be used for certain types of services, or not at all. An option that shouldn't be used in newly written units shouldn't be used in generated ones either. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Tue, Oct 01, 2013 at 10:57:17AM +0200, Thomas Bächler wrote: > Am 01.10.2013 05:10, schrieb Lennart Poettering: > b) is tempting. Given fsck's improved internal ordering handling, is > there actually a usecase for ordering the fsck's? I can't think of any > off the top of my head... > >>> > >>> I struggle coming up with one. I mean, the only I could think of is "oh > >>> my, it always used to work that way, and it is documented that way, you > >>> break UNIX!", which isn't even a usecase, but just confusion. > > Those were exactly my thoughts. And since systemd never had a problem > with breaking tradition if it was a good idea, I thought we could simply > go ahead. > > Now, according to the fstab(5) manpage, the root fs should have passno 1 > and everything else should have passno 2. We could ensure the same > behaviour by having After=systemd-root-fsck.service in > systemd-fsck@.service. Serializing fscks like that makes only limited sense if you're doing it from the initrd. But if the fsck is run from the ro root, then yes, I guess you want to make sure that the fs that holds the fsck binaries is OK before continuing. I think that since you're defining completly new behaviour, it would be nice to implement this smartly, to avoid constraining parallelization artificially. > If file system checks actually need to be manually ordered in a certain > manner (which I would consider an edge case), systemd provides a much > saner interface than a "pass number", namely Before= and After= ordering > on the fsck services using .d files. I'm not sure if it is saner. It is more verbose and complicated, and most people like to configure their fsck's through /etc/fstab, since it is more convinient than .d directories. Manual ordering is a bit of a corner case, but like Jan Engelhart wrote... > On an iSCSI server, export /dev/sdf1 and /dev/sdf2 as separate LUNs. > The iSCSI client will import them as /dev/sda and /dev/sdb. That is a > case where, if you can, you would specify FsckPassNo because the > automatic detection likely stops at host boundaries. ...there might be use cases. Even if we drop support for ordering by fsck-no field in /etc/fstab, do we have a new way of configuring this through /etc/fstab? (Something like x-systemd.comment=After=systemd-fsck-var.service ?) Or is this really too much of an edge case? I don't think that the current fsck-no-related code is harmful in any way or a maintenance burden, so if it is dropped, it would be nice to cover all bases. > >> Things like that should probably just be automatically determined by > >> the machine, and not requiring a human to invent weird passes to do > >> the job. A boolean sounds fine to me. > > As Kay mentioned, /sbin/fsck is rather powerful these days. +1, as long as we don't break more complicated setups. > > OK, sounds good to me. Anyone wants to cook up a patch that removes > > FsckPassNo= from the core and makes sure the fstab generator only takes > > the "passno" field in fstab as boolean to enable fsck or not? > > My patch 1/3 already treats passno as a boolean - if passno > 0, we > enable fsck, otherwise we don't. (passno < 0 is treated the same as > passno == 0 by the current FsckPassNo code, so I kept that.) > > I can cook up a patch that removes FsckPassNo= - I omitted it here since > I was unsure whether people have it in unit files they wrote manually. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
Am 01.10.2013 05:10, schrieb Lennart Poettering: b) is tempting. Given fsck's improved internal ordering handling, is there actually a usecase for ordering the fsck's? I can't think of any off the top of my head... >>> >>> I struggle coming up with one. I mean, the only I could think of is "oh >>> my, it always used to work that way, and it is documented that way, you >>> break UNIX!", which isn't even a usecase, but just confusion. Those were exactly my thoughts. And since systemd never had a problem with breaking tradition if it was a good idea, I thought we could simply go ahead. Now, according to the fstab(5) manpage, the root fs should have passno 1 and everything else should have passno 2. We could ensure the same behaviour by having After=systemd-root-fsck.service in systemd-fsck@.service. If file system checks actually need to be manually ordered in a certain manner (which I would consider an edge case), systemd provides a much saner interface than a "pass number", namely Before= and After= ordering on the fsck services using .d files. >> Things like that should probably just be automatically determined by >> the machine, and not requiring a human to invent weird passes to do >> the job. A boolean sounds fine to me. As Kay mentioned, /sbin/fsck is rather powerful these days. > OK, sounds good to me. Anyone wants to cook up a patch that removes > FsckPassNo= from the core and makes sure the fstab generator only takes > the "passno" field in fstab as boolean to enable fsck or not? My patch 1/3 already treats passno as a boolean - if passno > 0, we enable fsck, otherwise we don't. (passno < 0 is treated the same as passno == 0 by the current FsckPassNo code, so I kept that.) I can cook up a patch that removes FsckPassNo= - I omitted it here since I was unsure whether people have it in unit files they wrote manually. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Tuesday 2013-10-01 04:29, Lennart Poettering wrote: >> > >> > b) declare that manual passno configuration is stupid beyond treating it >> >as simple boolean. In thatc ase we should drop all references of >> >passno in the sources. Of course people might complain that we break >> >compat with UNIX, but well... >> > >> > If we go for b) then I figure people might complain that fstab(5) is not >> > longer compatible with what systemd does? >> >> b) is tempting. Given fsck's improved internal ordering handling, is >> there actually a usecase for ordering the fsck's? I can't think of any >> off the top of my head... > >I struggle coming up with one. On an iSCSI server, export /dev/sdf1 and /dev/sdf2 as separate LUNs. The iSCSI client will import them as /dev/sda and /dev/sdb. That is a case where, if you can, you would specify FsckPassNo because the automatic detection likely stops at host boundaries. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Tue, 01.10.13 04:42, Kay Sievers (k...@vrfy.org) wrote: > > On Tue, Oct 1, 2013 at 4:29 AM, Lennart Poettering > wrote: > > On Tue, 01.10.13 04:19, Tom Gundersen (t...@jklm.no) wrote: > > > >> > I'd love to get rid of FsckPassNo=, but I fear that's not that > >> > easy... After all it's not just a boolean, it actually influences the > >> > ordering of the fsck. There traditionally were two documented phases > >> > which you could use to serialize multiple fsck on the same HDD > >> > but different partitions, but parallelize it on different HDDs. Now, > >> > fsck since a while can determine all that automatically these days. But > >> > still by using FsckPassNo= you get ordering deps automatically added. > >> > > >> > a) leave everything as is and FsckPassNo= does odering deps > >> > > >> > b) declare that manual passno configuration is stupid beyond treating it > >> >as simple boolean. In thatc ase we should drop all references of > >> >passno in the sources. Of course people might complain that we break > >> >compat with UNIX, but well... > >> > > >> > c) Pimp up fstab-generator to write complete unit files for > >> >fsck@.service that include the right dependencies. Meh. > >> > > >> > d) Pimp up fstab-generator to write only .d dropins that add the > >> >necessary deps between the fsck instances, but nothing else. > >> > > >> > I think c) and a) suck. b) sounds like the best option to me. d) sounds > >> > workable too. > >> > > >> > If we go for b) then I figure people might complain that fstab(5) is not > >> > longer compatible with what systemd does? > >> > >> b) is tempting. Given fsck's improved internal ordering handling, is > >> there actually a usecase for ordering the fsck's? I can't think of any > >> off the top of my head... > > > > I struggle coming up with one. I mean, the only I could think of is "oh > > my, it always used to work that way, and it is documented that way, you > > break UNIX!", which isn't even a usecase, but just confusion. > > > > I have the suspicion that if we remove support for it, and don't tell > > anyone nobody might actually notice. > > > > So maybe we should just go ahead and change it to become a boolean only, > > and not tell anyone, and that's it? Opinions? > > Things like that should probably just be automatically determined by > the machine, and not requiring a human to invent weird passes to do > the job. A boolean sounds fine to me. OK, sounds good to me. Anyone wants to cook up a patch that removes FsckPassNo= from the core and makes sure the fstab generator only takes the "passno" field in fstab as boolean to enable fsck or not? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Tue, Oct 1, 2013 at 4:29 AM, Lennart Poettering wrote: > On Tue, 01.10.13 04:19, Tom Gundersen (t...@jklm.no) wrote: > >> > I'd love to get rid of FsckPassNo=, but I fear that's not that >> > easy... After all it's not just a boolean, it actually influences the >> > ordering of the fsck. There traditionally were two documented phases >> > which you could use to serialize multiple fsck on the same HDD >> > but different partitions, but parallelize it on different HDDs. Now, >> > fsck since a while can determine all that automatically these days. But >> > still by using FsckPassNo= you get ordering deps automatically added. >> > >> > a) leave everything as is and FsckPassNo= does odering deps >> > >> > b) declare that manual passno configuration is stupid beyond treating it >> >as simple boolean. In thatc ase we should drop all references of >> >passno in the sources. Of course people might complain that we break >> >compat with UNIX, but well... >> > >> > c) Pimp up fstab-generator to write complete unit files for >> >fsck@.service that include the right dependencies. Meh. >> > >> > d) Pimp up fstab-generator to write only .d dropins that add the >> >necessary deps between the fsck instances, but nothing else. >> > >> > I think c) and a) suck. b) sounds like the best option to me. d) sounds >> > workable too. >> > >> > If we go for b) then I figure people might complain that fstab(5) is not >> > longer compatible with what systemd does? >> >> b) is tempting. Given fsck's improved internal ordering handling, is >> there actually a usecase for ordering the fsck's? I can't think of any >> off the top of my head... > > I struggle coming up with one. I mean, the only I could think of is "oh > my, it always used to work that way, and it is documented that way, you > break UNIX!", which isn't even a usecase, but just confusion. > > I have the suspicion that if we remove support for it, and don't tell > anyone nobody might actually notice. > > So maybe we should just go ahead and change it to become a boolean only, > and not tell anyone, and that's it? Opinions? Things like that should probably just be automatically determined by the machine, and not requiring a human to invent weird passes to do the job. A boolean sounds fine to me. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Tue, 01.10.13 04:19, Tom Gundersen (t...@jklm.no) wrote: > > I'd love to get rid of FsckPassNo=, but I fear that's not that > > easy... After all it's not just a boolean, it actually influences the > > ordering of the fsck. There traditionally were two documented phases > > which you could use to serialize multiple fsck on the same HDD > > but different partitions, but parallelize it on different HDDs. Now, > > fsck since a while can determine all that automatically these days. But > > still by using FsckPassNo= you get ordering deps automatically added. > > > > a) leave everything as is and FsckPassNo= does odering deps > > > > b) declare that manual passno configuration is stupid beyond treating it > >as simple boolean. In thatc ase we should drop all references of > >passno in the sources. Of course people might complain that we break > >compat with UNIX, but well... > > > > c) Pimp up fstab-generator to write complete unit files for > >fsck@.service that include the right dependencies. Meh. > > > > d) Pimp up fstab-generator to write only .d dropins that add the > >necessary deps between the fsck instances, but nothing else. > > > > I think c) and a) suck. b) sounds like the best option to me. d) sounds > > workable too. > > > > If we go for b) then I figure people might complain that fstab(5) is not > > longer compatible with what systemd does? > > b) is tempting. Given fsck's improved internal ordering handling, is > there actually a usecase for ordering the fsck's? I can't think of any > off the top of my head... I struggle coming up with one. I mean, the only I could think of is "oh my, it always used to work that way, and it is documented that way, you break UNIX!", which isn't even a usecase, but just confusion. I have the suspicion that if we remove support for it, and don't tell anyone nobody might actually notice. So maybe we should just go ahead and change it to become a boolean only, and not tell anyone, and that's it? Opinions? Lennart PS: And pst! It's now totally secret, don't tell anyone about this! Pssst! -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Tue, Oct 1, 2013 at 3:07 AM, Lennart Poettering wrote: > On Mon, 30.09.13 01:34, Thomas Bächler (tho...@archlinux.org) wrote: > > I'd love to get rid of FsckPassNo=, but I fear that's not that > easy... After all it's not just a boolean, it actually influences the > ordering of the fsck. There traditionally were two documented phases > which you could use to serialize multiple fsck on the same HDD > but different partitions, but parallelize it on different HDDs. Now, > fsck since a while can determine all that automatically these days. But > still by using FsckPassNo= you get ordering deps automatically added. > > a) leave everything as is and FsckPassNo= does odering deps > > b) declare that manual passno configuration is stupid beyond treating it >as simple boolean. In thatc ase we should drop all references of >passno in the sources. Of course people might complain that we break >compat with UNIX, but well... > > c) Pimp up fstab-generator to write complete unit files for >fsck@.service that include the right dependencies. Meh. > > d) Pimp up fstab-generator to write only .d dropins that add the >necessary deps between the fsck instances, but nothing else. > > I think c) and a) suck. b) sounds like the best option to me. d) sounds > workable too. > > If we go for b) then I figure people might complain that fstab(5) is not > longer compatible with what systemd does? b) is tempting. Given fsck's improved internal ordering handling, is there actually a usecase for ordering the fsck's? I can't think of any off the top of my head... -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Mon, 30.09.13 01:34, Thomas Bächler (tho...@archlinux.org) wrote:
I'd love to get rid of FsckPassNo=, but I fear that's not that
easy... After all it's not just a boolean, it actually influences the
ordering of the fsck. There traditionally were two documented phases
which you could use to serialize multiple fsck on the same HDD
but different partitions, but parallelize it on different HDDs. Now,
fsck since a while can determine all that automatically these days. But
still by using FsckPassNo= you get ordering deps automatically added.
a) leave everything as is and FsckPassNo= does odering deps
b) declare that manual passno configuration is stupid beyond treating it
as simple boolean. In thatc ase we should drop all references of
passno in the sources. Of course people might complain that we break
compat with UNIX, but well...
c) Pimp up fstab-generator to write complete unit files for
fsck@.service that include the right dependencies. Meh.
d) Pimp up fstab-generator to write only .d dropins that add the
necessary deps between the fsck instances, but nothing else.
I think c) and a) suck. b) sounds like the best option to me. d) sounds
workable too.
If we go for b) then I figure people might complain that fstab(5) is not
longer compatible with what systemd does?
Opinions?
> ---
> src/fstab-generator/fstab-generator.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/src/fstab-generator/fstab-generator.c
> b/src/fstab-generator/fstab-generator.c
> index 6cecb4e..83aba7d 100644
> --- a/src/fstab-generator/fstab-generator.c
> +++ b/src/fstab-generator/fstab-generator.c
> @@ -209,17 +209,26 @@ static int add_mount(
> "Before=%s\n",
> post);
>
> +if (passno > 0) {
> +_cleanup_free_ char *fsck = NULL;
> +fsck = unit_name_from_path_instance("systemd-fsck", what,
> ".service");
> +fprintf(f,
> +"Requires=%s\n"
> +"After=%s\n",
> +fsck,
> +fsck);
> +}
> +
> +
> fprintf(f,
> "\n"
> "[Mount]\n"
> "What=%s\n"
> "Where=%s\n"
> -"Type=%s\n"
> -"FsckPassNo=%i\n",
> +"Type=%s\n",
> what,
> where,
> -type,
> -passno);
> +type);
>
> if (!isempty(opts) &&
> !streq(opts, "defaults"))
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
---
src/fstab-generator/fstab-generator.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 6cecb4e..83aba7d 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -209,17 +209,26 @@ static int add_mount(
"Before=%s\n",
post);
+if (passno > 0) {
+_cleanup_free_ char *fsck = NULL;
+fsck = unit_name_from_path_instance("systemd-fsck", what,
".service");
+fprintf(f,
+"Requires=%s\n"
+"After=%s\n",
+fsck,
+fsck);
+}
+
+
fprintf(f,
"\n"
"[Mount]\n"
"What=%s\n"
"Where=%s\n"
-"Type=%s\n"
-"FsckPassNo=%i\n",
+"Type=%s\n",
what,
where,
-type,
-passno);
+type);
if (!isempty(opts) &&
!streq(opts, "defaults"))
--
1.8.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
