The idea that separate / from /usr is archaic or wrong is incorrect. Just
saying... Think about it for a bit... Because if you still believe that to be
true...then it is /usr that must go away. Sure, we are like lemmings and we
follow whoever we think should lead...I'm just saying we need to be
On Fri, Sep 30, 2011 at 5:23 PM, Paolo Bonzini wrote:
> It's actually pretty hard unless you give up the ability to replay/collect
> at the same time, which I think would be really bad. The problem is that
> replay will read files for "after basic.target" long before that target has
> completed,
On 09/30/2011 04:52 PM, Tom Gundersen wrote:
How about this:
Rather than making the split between / and /usr, make it between
Before and After basic.target (as basic.target is roughly what
traditionally would require files to be on /). This would require us
to associate files to be readahead wit
On Fri, Sep 30, 2011 at 4:26 PM, Paolo Bonzini wrote:
> On 09/30/2011 03:39 PM, Kay Sievers wrote:
>>
>> Sure. I just think that this is not what we really want in the end.
>
> That I agree with, but good is the enemy of perfect...
How about this:
Rather than making the split between / and /usr,
On 09/30/2011 03:39 PM, Kay Sievers wrote:
Sure. I just think that this is not what we really want in the end.
That I agree with, but good is the enemy of perfect...
Paolo
___
systemd-devel mailing list
[email protected]
http://list
On Fri, Sep 30, 2011 at 15:25, Paolo Bonzini wrote:
> On 09/30/2011 03:08 PM, Kay Sievers wrote:
>> /usr will not be a good rule, and hard coding such things in the code,
>> we should should probably avoid in general.
> Even if it will not be a good rule, right now it is at least decent, and
> r
On 09/30/2011 03:08 PM, Kay Sievers wrote:
You did not read any of the pages behind the links in the earlier
mail, right?:)
Gotcha. :)
>> Rules which files to prioritize *might* make sense, sorting by
>> top-level dir doesn't really.
Nah, I meant something different. Your hardcoded /usr i
On Fri, Sep 30, 2011 at 14:31, Paolo Bonzini wrote:
> On 09/30/2011 01:32 PM, Kay Sievers wrote:
>>>
>>> So much that I've
>>> been thinking about adding "virtual" mount units that become active as
>>> soon
>>> as any directory above it is mounted. This way, units that require /usr
>>> could be m
On 09/30/2011 01:32 PM, Kay Sievers wrote:
So much that I've
been thinking about adding "virtual" mount units that become active as soon
as any directory above it is mounted. This way, units that require /usr
could be made to depend on usr.mount.
No, this will all not work for any non-trivial
Le vendredi 30 septembre 2011 à 13:32 +0200, Kay Sievers a écrit :
> On Fri, Sep 30, 2011 at 13:18, Paolo Bonzini wrote:
> > On 09/30/2011 01:05 PM, Tom Gundersen wrote:
> >>
> >> Also, I'm not sure if I understand your suggestion that /var should be
> >> ignored. In particular I think /var/tmp w
On Fri, Sep 30, 2011 at 13:18, Paolo Bonzini wrote:
> On 09/30/2011 01:05 PM, Tom Gundersen wrote:
>>
>> I think a better heuristic is needed if we want to plan for
>> the future. If I understand correctly, there seems to be a shift
>> towards moving stuff from /lib, /bin and /sbin to /usr/lib, /u
Hi,
currently, all LSB initscripts have RemainAfterExit=true, since pidfile
is not available in the header (unlike "fedora" like headers). This is
problematic when a daemon started from an initscript gets killed (or
something similar), because the service still looks active (see
https://bugzilla.n
[adding back the list]
On 09/30/2011 01:05 PM, Tom Gundersen wrote:
I think a better heuristic is needed if we want to plan for
the future. If I understand correctly, there seems to be a shift
towards moving stuff from /lib, /bin and /sbin to /usr/lib, /usr/bin
and /usr/sbin, respectively (and r
When enabling readahead on my system (which has a 5400rpm hard drive)
"systemd-analyze blame" output is like this:
19507ms udev.service
18336ms fedora-storage-init.service
13254ms var-lock.mount
12960ms var-run.mount
12871ms media.mount
This matches visual feedback from system
14 matches
Mail list logo
