Hi Kay,
2011/3/28 Kay Sievers :
> On Fri, Mar 18, 2011 at 14:57, Kay Sievers wrote:
>
> Udev no longer enables udev-settle.service by default now.
> basic.target is no longer blocked by it, and udev's coldplug will run
> in the background.
To make boot fast, it seems udev's coldplug do too much j
2011/3/28 Lennart Poettering :
> On Sun, 20.03.11 05:28, [email protected] ([email protected]) wrote:
>> Current readahead implementation has some problems:
>> 1. It can't separate *real* block read requests from all read
>> requests(which includes more blocks read by the kernel's readahead
>> logi
On Fri, Mar 18, 2011 at 14:57, Kay Sievers wrote:
> On Fri, Mar 18, 2011 at 14:40, Gustavo Sverzut Barbieri
>> But it could be improved yes. As you all said, maybe we should handle
>> udev hotplug in a more throttled way by postponing non-critical
>> devices and having everything else to be hotpl
On Tue, 29.03.11 00:21, Kay Sievers ([email protected]) wrote:
> >>It's the other way round.
> >>
> >>We want to get rid of the hidden-files-in-/dev mess. Hence all those
> >>dirs will move to /run/ and /var/run will simply point to that.
> >
> > Ok that makes sense. But will /run stick around
On Tue, Mar 29, 2011 at 00:11, Jan Engelhardt wrote:
> On Monday 2011-03-28 23:55, Lennart Poettering wrote:
>>On Mon, 28.03.11 23:46, Jan Engelhardt ([email protected]) wrote:
>>> On Monday 2011-03-28 23:04, Lennart Poettering wrote:
>>> >On Fri, 25.03.11 05:07, Kay Sievers ([email protected]
On Monday 2011-03-28 23:55, Lennart Poettering wrote:
>On Mon, 28.03.11 23:46, Jan Engelhardt ([email protected]) wrote:
>
>>
>> On Monday 2011-03-28 23:04, Lennart Poettering wrote:
>>
>> >On Fri, 25.03.11 05:07, Kay Sievers ([email protected]) wrote:
>> >
>> >> Instead of the /dev/.run tri
On Monday 2011-03-28 23:29, Lennart Poettering wrote:
>On Sun, 27.03.11 23:52, Jan Engelhardt ([email protected]) wrote:
>
>>
>> On Friday 2011-03-18 01:41, Lennart Poettering wrote:
>>
>> >On Fri, 18.03.11 00:18, Jan Engelhardt ([email protected]) wrote:
>> >
>> >> Meanwhile, I have two new s
On Mon, 28.03.11 23:46, Jan Engelhardt ([email protected]) wrote:
>
> On Monday 2011-03-28 23:04, Lennart Poettering wrote:
>
> >On Fri, 25.03.11 05:07, Kay Sievers ([email protected]) wrote:
> >
> >> Instead of the /dev/.run trick we have currently implemented, we decided
> >> to move the e
Ludwig Nussel wrote:
> mount --bind /var/run /mnt
> mount /var
> mount -M /mnt /var/run
>
This doesn't work. It means there is a period during boot where
/var/run suddenly vanishes (when mount the separate /var).
You have to do:
mount DEV_OF_VAR /mnt
mount --bind /var/run /mnt/run
mount -M /mnt
On Mon, Mar 28, 2011 at 23:46, Jan Engelhardt wrote:
> On Monday 2011-03-28 23:04, Lennart Poettering wrote:
>
>>On Fri, 25.03.11 05:07, Kay Sievers ([email protected]) wrote:
>>
>>> Instead of the /dev/.run trick we have currently implemented, we decided
>>> to move the early-boot runtime dir
On Monday 2011-03-28 23:04, Lennart Poettering wrote:
>On Fri, 25.03.11 05:07, Kay Sievers ([email protected]) wrote:
>
>> Instead of the /dev/.run trick we have currently implemented, we decided
>> to move the early-boot runtime dir to /run.
>
>Applied (and fixed a few minor issues).
Uhm, *co
On Mon, 21.03.11 17:16, Michael Olbrich ([email protected]) wrote:
> +SUBSYSTEM=="tty", KERNEL=="ttyAM*", TAG+="systemd"
> +SUBSYSTEM=="tty", KERNEL=="ttymxc*", TAG+="systemd"
> +SUBSYSTEM=="tty", KERNEL=="ttyPSC*", TAG+="systemd"
Applied. Thanks a lot!
Lennart
--
Lennart Poettering - R
On Sun, 27.03.11 23:52, Jan Engelhardt ([email protected]) wrote:
>
> On Friday 2011-03-18 01:41, Lennart Poettering wrote:
>
> >On Fri, 18.03.11 00:18, Jan Engelhardt ([email protected]) wrote:
> >
> >> Meanwhile, I have two new suggestions.
> >
> >I have one too (or actually Kay came up with
On Fri, 25.03.11 05:07, Kay Sievers ([email protected]) wrote:
> Instead of the /dev/.run trick we have currently implemented, we decided
> to move the early-boot runtime dir to /run.
Applied (and fixed a few minor issues).
Lennart
--
Lennart Poettering - Red Hat, Inc.
_
On Wed, 23.03.11 19:55, nerdopolis ([email protected]) wrote:
> > I think chroot can be a useful tool for jailing particular services into
> > subtrees of the fs hierarchy. Either in the way that the service itself
> > internally chroot()s (which Avahi does, as I think the only servic
On Tue, 22.03.11 20:53, Andrey Borzenkov ([email protected]) wrote:
> I'm about to enable pam_systemd globally, but now I am a bit unsure
> where should it go in. I'd rather put it in default system-auth which
> is included by most other modules; but it also includes some modules
> that I am not
On Thu, 24.03.11 10:20, Gustavo Sverzut Barbieri ([email protected])
wrote:
> On Thu, Mar 24, 2011 at 9:35 AM, Andrey Borzenkov wrote:
> > On Thu, Mar 24, 2011 at 12:19 PM, [email protected]
> > wrote:
> >> Hi,
> >>
> >> 2011/3/18 Gustavo Sverzut Barbieri :
> >>> 2. should we do (or hav
On Sun, 20.03.11 05:28, [email protected] ([email protected]) wrote:
>
> 2011/3/19 Chen Jie :
> > 2011/3/18 Kay Sievers :
> >>
> >> It's ~0.5 sec faster here with readahead on a SSD.
> > Each time runs readahead-replay may cause readahead-collect to record
> > more blocks to read ahead -- size of
On Sat, 19.03.11 06:05, Chen Jie ([email protected]) wrote:
>
> 2011/3/18 Kay Sievers :
> > On Fri, Mar 18, 2011 at 14:40, Gustavo Sverzut Barbieri
> > wrote:
> >> On Fri, Mar 18, 2011 at 10:52 AM, Andrey Borzenkov
> >> wrote:
> >>> On Fri, Mar 18, 2011 at 12:35 PM, [email protected]
> >>> wr
On Mon, 21.03.11 08:37, [email protected] ([email protected]) wrote:
> The third version if this patch.
> Changes since v2:
> 1. page_size() uses assert_se(sysconf(...)) to detect failure of
> sysconf, abort if sysconf fails.
>
> 2011/3/19 Jan Engelhardt :
> > On Saturday 2011-03-19 07:18, fykc..
于 2011年03月28日 22:36, Jan Engelhardt 写道:
> On Monday 2011-03-28 16:25, Ludwig Nussel wrote:
>
>> Kay Sievers wrote:
>>> On Mon, Mar 28, 2011 at 13:28, Ludwig Nussel wrote:
Bill Nottingham wrote:
> Andrey Borzenkov ([email protected]) said:
>> On Fri, Mar 25, 2011 at 7:07 AM, Kay Sie
On Monday 2011-03-28 16:25, Ludwig Nussel wrote:
>Kay Sievers wrote:
>> On Mon, Mar 28, 2011 at 13:28, Ludwig Nussel wrote:
>> > Bill Nottingham wrote:
>> >> Andrey Borzenkov ([email protected]) said:
>> >> > On Fri, Mar 25, 2011 at 7:07 AM, Kay Sievers
>> >> > wrote:
>> >> > > Instead of the
Kay Sievers wrote:
> On Mon, Mar 28, 2011 at 13:28, Ludwig Nussel wrote:
> > Bill Nottingham wrote:
> >> Andrey Borzenkov ([email protected]) said:
> >> > On Fri, Mar 25, 2011 at 7:07 AM, Kay Sievers
> >> > wrote:
> >> > > Instead of the /dev/.run trick we have currently implemented, we
> >>
On Mon, Mar 28, 2011 at 13:28, Ludwig Nussel wrote:
> Bill Nottingham wrote:
>> Andrey Borzenkov ([email protected]) said:
>> > On Fri, Mar 25, 2011 at 7:07 AM, Kay Sievers wrote:
>> > > Instead of the /dev/.run trick we have currently implemented, we decided
>> > > to move the early-boot runti
/dev/.run is just fine, and /dev is tmpfs backend, so that is fast.
/var is not tmpfs backend.
2011/3/28 Ludwig Nussel :
> Bill Nottingham wrote:
>> Andrey Borzenkov ([email protected]) said:
>> > On Fri, Mar 25, 2011 at 7:07 AM, Kay Sievers wrote:
>> > > Instead of the /dev/.run trick we have
Bill Nottingham wrote:
> Andrey Borzenkov ([email protected]) said:
> > On Fri, Mar 25, 2011 at 7:07 AM, Kay Sievers wrote:
> > > Instead of the /dev/.run trick we have currently implemented, we decided
> > > to move the early-boot runtime dir to /run.
> > >
> >
> > What is the benefit? /var/r
26 matches
Mail list logo