I resend patch as v2 with fixed todo
2014-07-21 9:16 GMT+03:00 Timofey Titovets :
> 2014-07-21 5:21 GMT+03:00 Andrey Borzenkov :
>> В Sun, 20 Jul 2014 22:27:20 +0300
>> Timofey Titovets пишет:
>>
>>> Just completed TODO:
>>> * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
>>>
Just completed TODO:
* readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
//i save BTRFS_IOC_DEFRAG as fallback, because BTRFS_IOC_DEFRAG_RANGE
not working (as i know) on several old kernels
v1 -> v2
Fixed spelling in TODO
TODO | 1 -
src/rea
2014-07-21 5:21 GMT+03:00 Andrey Borzenkov :
> В Sun, 20 Jul 2014 22:27:20 +0300
> Timofey Titovets пишет:
>
>> Just completed TODO:
>> * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
>>
>
> It would be helpful to give explanation "why" for future reference.
>
>>
>> +/* TODO: F
В Sun, 20 Jul 2014 22:27:20 +0300
Timofey Titovets пишет:
> Just completed TODO:
> * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
>
It would be helpful to give explanation "why" for future reference.
>
> +/* TODO: Fix: wan't compile it it struct in ifndef HAVE_LINUX_BTRFS
On Thu, Jul 17, 2014 at 08:51:52PM +0200, Thomas H.P. Andersen wrote:
> From recent commits I have noticed the following new issues from
> static analysis with scan-build and with clang. I am not sure how they
> should be fixed (or even if) but I just though I would let you know.
>
> 1) src/shared
On Sun, Jul 20, 2014 at 11:30:20PM +0100, Colin Guthrie wrote:
> 'Twas brillig, and Reindl Harald at 20/07/14 22:52 did gyre and gimble:
> >
> > Am 20.07.2014 23:38, schrieb Colin Guthrie:
> >> 'Twas brillig, and Colin Guthrie at 20/07/14 22:31 did gyre and gimble:
> >>> Those defaults could be se
On Sun, Jul 20, 2014 at 06:10:07PM -0700, [email protected] wrote:
> Hi,
>
> On Sun, Jul 20, 2014, at 05:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > 2. tell systemd to log less with 'systemd-analyze set-log-level notice'.
>
> Won't that lower the log level 'into' the journal as well?
Yes.
Hi,
On Sun, Jul 20, 2014, at 05:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
> 2. tell systemd to log less with 'systemd-analyze set-log-level notice'.
Won't that lower the log level 'into' the journal as well? I'm happy to have
that populated with a high level of detail -- I just don't want 'nois
On Sun, Jul 20, 2014 at 03:41:46PM -0700, [email protected] wrote:
> Hi
>
> I checked at
>
> http://lists.freedesktop.org/mailman/listinfo
>
> for a user-specific list for systemd; N/A, afaict. looks like this is the
> right one?
Yes.
> 2014-07-20T15:15:01.538078-07:
Hi
I checked at
http://lists.freedesktop.org/mailman/listinfo
for a user-specific list for systemd; N/A, afaict. looks like this is the
right one?
I currently have
systemd --version
systemd 210
+PAM +LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LI
'Twas brillig, and Reindl Harald at 20/07/14 22:52 did gyre and gimble:
>
> Am 20.07.2014 23:38, schrieb Colin Guthrie:
>> 'Twas brillig, and Colin Guthrie at 20/07/14 22:31 did gyre and gimble:
>>> Those defaults could be set from a compile time check of
>>> login.defs too.
>>
>> FWIW, at least h
Am 20.07.2014 23:38, schrieb Colin Guthrie:
> 'Twas brillig, and Colin Guthrie at 20/07/14 22:31 did gyre and gimble:
>> Those defaults could be set from a compile time check of
>> login.defs too.
>
> FWIW, at least here, /etc/login.defs is not readable by regular users so
> any build system that
'Twas brillig, and Colin Guthrie at 20/07/14 22:31 did gyre and gimble:
> Those defaults could be set from a compile time check of
> login.defs too.
FWIW, at least here, /etc/login.defs is not readable by regular users so
any build system that builds as non-root won't even get those defaults
anywa
Hi,
We're still using 500 as our [UG]ID_MIN in /etc/login.defs, but I'm
looking to change that to be more in line with what everyone else seems
to do.
One thing I found while looking at the sysusers code was that the only
values read from /etc/login.defs were SYSTEM_[UG]ID_MAX and they were
only
What's so special about i686!?
systemd[1]: Failed to start Login Service.
systemd[1]: Unit systemd-logind.service entered failed state.
systemd[1]: systemd-logind.service has no holdoff time, scheduling restart.
https://bugzilla.redhat.com/show_bug.cgi?id=1121419
poma
___
Just completed TODO:
* readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
TODO | 1 -
src/readahead/readahead-collect.c | 22 +-
src/shared/missing.h | 15 +++
3 files changed, 32 insertions(+), 6 dele
Hi,
Short answer is YES to your first question. For long answer,
http://0pointer.de/blog/projects/stateless.html.
Umut
> On Jul 19, 2014, at 5:04 PM, "lux-integ" wrote:
>
> Greetings,
>
> I have a computer with these
> --OS Linux 64bit BLFS Linux
> --relatively recent version of systemd
>
On Sun, Jul 20, 2014 at 3:12 PM, Michael Olbrich
wrote:
>
> with the current git master (v215-293-g4e6029435111) restarting
> systemd-networkd triggers an assert() here:
>
> In netdev_join_handler():
> assert(IN_SET(link->state, LINK_STATE_ENSLAVING, LINK_STATE_FAILED,
>
Hi,
with the current git master (v215-293-g4e6029435111) restarting
systemd-networkd triggers an assert() here:
In netdev_join_handler():
assert(IN_SET(link->state, LINK_STATE_ENSLAVING, LINK_STATE_FAILED,
LINK_STATE_LINGER));
gdb tells me that link->state is LINK_S
19 matches
Mail list logo
