Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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. 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? Shouldn't move ZRAM first move out of staging? Ofcourse but when it does move out of staging we could have sorted this implementation detail out which basically boils down to where to set the partition sizes for the zram partitions ( tmpfiles.d/zram-conf or /etc/zram.d/zram-conf ) Do we want a script that basically just set this size based on available memory per core in the udev rule. factor=25 num_cpus=$(grep -c processor /proc/cpuinfo) memtotal=$(grep MemTotal /proc/meminfo | sed 's/[^0-9]\+//g') mem_by_cpu=$(($memtotal/$num_cpus*$factor/100*1024)) echo $mem_by_cpu [Side note: I'm reading Documentation/blockdev/zram.txt... It says 1. modprobe zram num_devices=4. I can't help thinking that we went over this with /dev/loop-control and others... Since this is a new interface, why does it repeat the same pitfall of not having a control device?] We can always change this now, quick, before 3.14 is out. What would a control device help with here? 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 loop. Given that the code doesn't have the ability to dynamically add/remove devices, I think we are stuck with this, right? greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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 loop. Given that the code doesn't have the ability to dynamically add/remove devices, I think we are stuck with this, right? This may come as a completely stupid question but if the code is expected to be able to dynamically add/remove devices should not upstream ( kernel ) nack inclusion of zram until it does? I don't think the code is expected to be able to do that, have you looked at it and seen where it does? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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 to look for one. The same issues as with loop. Given that the code doesn't have the ability to dynamically add/remove devices, I think we are stuck with this, right? This may come as a completely stupid question but if the code is expected to be able to dynamically add/remove devices should not upstream ( kernel ) nack inclusion of zram until it does? I don't think the code is expected to be able to do that, have you looked at it and seen where it does? please re-read both posts in the last one clearly a not fails fixed version: This may come as a completely stupid question but if the code is *not* expected to be able to dynamically add/remove devices should not upstream ( kernel ) nack inclusion of zram until it does? 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] udev: Adding zram to inappropriate block device
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? Shouldn't move ZRAM first move out of staging? Ofcourse but when it does move out of staging we could have sorted this implementation detail out which basically boils down to where to set the partition sizes for the zram partitions ( tmpfiles.d/zram-conf or /etc/zram.d/zram-conf ) Do we want a script that basically just set this size based on available memory per core in the udev rule. factor=25 num_cpus=$(grep -c processor /proc/cpuinfo) memtotal=$(grep MemTotal /proc/meminfo | sed 's/[^0-9]\+//g') mem_by_cpu=$(($memtotal/$num_cpus*$factor/100*1024)) echo $mem_by_cpu [Side note: I'm reading Documentation/blockdev/zram.txt... It says 1. modprobe zram num_devices=4. I can't help thinking that we went over this with /dev/loop-control and others... Since this is a new interface, why does it repeat the same pitfall of not having a control device?] Wouldn't it be simplest to have a parameter in /etc/fstab, like x.zram-disk-size=XXX, which swapon would write to /sys/block/.../disksize? This would make everything centralized and synchronous from the point of view of the administrator. Lennart Poettering wrote: Quite frankly, I don't really see what the point is of involving a fake block device for this... I am happy to generically support stuff that makes sense, but this really and totally doesn't. It's a completely broken API. You can use those devices also for other things... At some level it makes sense to provide this generic functionality instead of complicating other subsystems. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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 .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 staging we could have sorted this implementation detail out which basically boils down to where to set the partition sizes for the zram partitions ( tmpfiles.d/zram-conf or /etc/zram.d/zram-conf ) Do we want a script that basically just set this size based on available memory per core in the udev rule. factor=25 num_cpus=$(grep -c processor /proc/cpuinfo) memtotal=$(grep MemTotal /proc/meminfo | sed 's/[^0-9]\+//g') mem_by_cpu=$(($memtotal/$num_cpus*$factor/100*1024)) echo $mem_by_cpu [Side note: I'm reading Documentation/blockdev/zram.txt... It says 1. modprobe zram num_devices=4. I can't help thinking that we went over this with /dev/loop-control and others... Since this is a new interface, why does it repeat the same pitfall of not having a control device?] We can always change this now, quick, before 3.14 is out. What would a control device help with here? Wouldn't it be simplest to have a parameter in /etc/fstab, like x.zram-disk-size=XXX, which swapon would write to /sys/block/.../disksize? This would make everything centralized and synchronous from the point of view of the administrator. Module paramaters are under control of the admin, but they are a mess, I agree. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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 udev's persistent storage rules to avoid probing any zram devices. Thanks, this explains why the patch is needed. But this should really be in the commit message :) Regarding the future of zram support in systemd should that not be added to fstab-generator and swap, with unit type ending in .zswap? No. Quite frankly, I don't really see what the point is of involving a fake block device for this... I am happy to generically support stuff that makes sense, but this really and totally doesn't. It's a completely broken API. I mean, I don't mind if people make use of this, but support for this should live outside of systemd. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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 staging we could have sorted this implementation detail out which basically boils down to where to set the partition sizes for the zram partitions ( tmpfiles.d/zram-conf or /etc/zram.d/zram-conf ) Do we want a script that basically just set this size based on available memory per core in the udev rule. factor=25 num_cpus=$(grep -c processor /proc/cpuinfo) memtotal=$(grep MemTotal /proc/meminfo | sed 's/[^0-9]\+//g') mem_by_cpu=$(($memtotal/$num_cpus*$factor/100*1024)) echo $mem_by_cpu There are bunch of things to consider JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
---
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 +14,7 @@ ACTION==add, SUBSYSTEM==module, KERNEL==block,
ATTR{parameters/events_dfl_
SUBSYSTEM!=block, GOTO=persistent_storage_end
# skip rules for inappropriate block devices
-KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*, GOTO=persistent_storage_end
+KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*,
GOTO=persistent_storage_end
# ignore partitions that span the entire disk
TEST==whole_disk, GOTO=persistent_storage_end
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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
+++ b/rules/60-persistent-storage.rules
@@ -14,7 +14,7 @@ ACTION==add, SUBSYSTEM==module, KERNEL==block,
ATTR{parameters/events_dfl_
SUBSYSTEM!=block, GOTO=persistent_storage_end
# skip rules for inappropriate block devices
-KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*, GOTO=persistent_storage_end
+KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*,
GOTO=persistent_storage_end
# ignore partitions that span the entire disk
TEST==whole_disk, GOTO=persistent_storage_end
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 files that do result in such links being created
by systemd.
See
http://lists.freedesktop.org/archives/systemd-devel/2014-February/016614.html
for my configuration files.
offtopic
One patch that would be useful, however, is to make systemd say this
system cannot hibernate if all swap devices are zrams.
/offtopic
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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 files that do result in such links being created by systemd. 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 udev's persistent storage rules to avoid probing any zram devices. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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 change my opinion by providing configuration files that do result in such links being created by systemd. 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 udev's persistent storage rules to avoid probing any zram devices. Thanks, this explains why the patch is needed. But this should really be in the commit message :) -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
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 links in /dev/disk pointing to any zram device. You can change my opinion by providing configuration files that do result in such links being created by systemd. 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 udev's persistent storage rules to avoid probing any zram devices. Thanks, this explains why the patch is needed. But this should really be in the commit message :) Regarding the future of zram support in systemd should that not be added to fstab-generator and swap, with unit type ending in .zswap? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
