On Thu, Feb 06, 2014 at 03:58:59AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Feb 06, 2014 at 03:27:07AM +0100, Greg KH wrote:
On Thu, Feb 06, 2014 at 01:31:37AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
Patch applied.
On Mon, Feb 03, 2014 at 10:33:37AM +, Jóhann B.
On Thu, Feb 06, 2014 at 04:54:59PM +, Jóhann B. Guðmundsson wrote:
On 02/06/2014 03:39 PM, Greg KH wrote:
Right now you have to decide before loading the module how many
devices you want. And also when trying to use a device (any device),
you have to look for one. The same issues as with
Am 06.02.2014 18:45, schrieb Greg KH:
On Thu, Feb 06, 2014 at 04:54:59PM +, Jóhann B. Guðmundsson wrote:
On 02/06/2014 03:39 PM, Greg KH wrote:
Right now you have to decide before loading the module how many
devices you want. And also when trying to use a device (any device),
you have
Patch applied.
On Mon, Feb 03, 2014 at 10:33:37AM +, Jóhann B. Guðmundsson wrote:
On 02/03/2014 09:36 AM, Holger Schurig wrote:
with unit type ending in .zswap
No, not another unit type. Instead better amend .swap unit types to
also know about ZRAM.
However, isn't this a bit early?
On Thu, Feb 06, 2014 at 01:31:37AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
Patch applied.
On Mon, Feb 03, 2014 at 10:33:37AM +, Jóhann B. Guðmundsson wrote:
On 02/03/2014 09:36 AM, Holger Schurig wrote:
with unit type ending in .zswap
No, not another unit type. Instead better amend
On Sun, 02.02.14 15:27, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
udev seems to have a race condition with swapon to see which can open
/dev/zram0 first, causing swapon to fail.
( seems to be most noticeable on arm devices one out of every 7 times or
something ) and this patches
On 02/03/2014 09:36 AM, Holger Schurig wrote:
with unit type ending in .zswap
No, not another unit type. Instead better amend .swap unit types to
also know about ZRAM.
However, isn't this a bit early? Shouldn't move ZRAM first move out of staging?
Ofcourse but when it does move out of
with unit type ending in .zswap
No, not another unit type. Instead better amend .swap unit types to
also know about ZRAM.
However, isn't this a bit early? Shouldn't move ZRAM first move out of staging?
___
systemd-devel mailing list
---
rules/60-persistent-storage.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/60-persistent-storage.rules
b/rules/60-persistent-storage.rules
index a4d009a..154ffd9 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -14,7
02.02.2014 19:29, Jóhann B. Guðmundsson wrote:
---
rules/60-persistent-storage.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/60-persistent-storage.rules
b/rules/60-persistent-storage.rules
index a4d009a..154ffd9 100644
--- a/rules/60-persistent-storage.rules
On 02/02/2014 01:39 PM, Alexander E. Patrakov wrote:
The patch is obviously harmless. However, I am not convinced that it
is needed, because in my setup (without this patch) there are no links
in /dev/disk pointing to any zram device. You can change my opinion by
providing configuration
02.02.2014 20:18, Jóhann B. Guðmundsson wrote:
On 02/02/2014 01:39 PM, Alexander E. Patrakov wrote:
The patch is obviously harmless. However, I am not convinced that it
is needed, because in my setup (without this patch) there are no links
in /dev/disk pointing to any zram device. You can
On 02/02/2014 02:27 PM, Alexander E. Patrakov wrote:
02.02.2014 20:18, Jóhann B. Guðmundsson wrote:
On 02/02/2014 01:39 PM, Alexander E. Patrakov wrote:
The patch is obviously harmless. However, I am not convinced that it
is needed, because in my setup (without this patch) there are no
13 matches
Mail list logo
