[arch-general] Better NILFS2 Support
I just spent some time setting up my new laptop with an SSD to use NILFS2 as its root filesystem and I'm very pleased with the performance. In an effort to get better support for NILFS2 in arch I've added a request to move nilfs-utils to the base group and submitted a patch to initscripts to bring up the nlfs_cleanerd daemon if root is formatted as NILFS2. If NILFS2 is used on other partitions the mount command brings up the daemon on it's own. These two bugs should make it easier to add NILFS2 support to the Arch Installation Framework. Related bugs here, patch comments welcome: http://bugs.archlinux.org/task/20260 http://bugs.archlinux.org/task/20261 Cheers, alexmat
On Thu, 22 Jul 2010 15:47:24 -0700 Alex Matviychuk <alexmat@gmail.com> wrote:
I just spent some time setting up my new laptop with an SSD to use NILFS2 as its root filesystem and I'm very pleased with the performance.
In an effort to get better support for NILFS2 in arch I've added a request to move nilfs-utils to the base group and submitted a patch to initscripts to bring up the nlfs_cleanerd daemon if root is formatted as NILFS2. If NILFS2 is used on other partitions the mount command brings up the daemon on it's own.
These two bugs should make it easier to add NILFS2 support to the Arch Installation Framework.
Related bugs here, patch comments welcome:
http://bugs.archlinux.org/task/20260 http://bugs.archlinux.org/task/20261
Cheers, alexmat
good stuff Alex. Now who wants to patch aif? (should be trivial if the FS behaves like the others). Dieter
On Thu, 22 Jul 2010 15:47:24 -0700 Alex Matviychuk <alexmat@gmail.com> wrote:
In an effort to get better support for NILFS2 in arch I've added a request to move nilfs-utils to the base group
I don't think that nilfs-utils should be moved to the base group. I agree with moving it to [core] but not to base, because base is assumed to be installed on every computer and packages in the base group are usually not listed in the depends array of a PKGBUILD. On the contrary I think there could be some other file system tools like jfsutils, lvm2 and xfsprogs be removed from the base group (not from [core]). They probably should be automatically installed if a partition is formatted with one of these filesystems by AIF. But usually people who are using these filesystems know what they are doing and know that they have to select these packages for installation. Heiko
On Sun, 1 Aug 2010 16:46:33 +0200 Heiko Baums <lists@baums-on-web.de> wrote:
I don't think that nilfs-utils should be moved to the base group. I agree with moving it to [core] but not to base, because base is assumed to be installed on every computer and packages in the base group are usually not listed in the depends array of a PKGBUILD.
On the contrary I think there could be some other file system tools like jfsutils, lvm2 and xfsprogs be removed from the base group (not from [core]).
I think this explanation makes sense. I just found this back: http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup So indeed, it seems like the goal is to remove all non-essential things (reiserfs, xfs, ..) from base.
They probably should be automatically installed if a partition is formatted with one of these filesystems by AIF. But usually people who are using these filesystems know what they are doing and know that they have to select these packages for installation.
Actually it's fairly trivial to "preselect" those packagas based on the filesystems used during the filesystem step. I believe some of it is already implemented in aif. Dieter
On Sun, 1 Aug 2010 16:46:33 +0200
Heiko Baums <lists@baums-on-web.de> wrote:
I don't
agree with moving it to [core] but not to base, because base is assumed to be installed on every computer and packages in the base group are usually not listed in the depends array of a PKGBUILD.
On the contrary I
like jfsutils, lvm2 and xfsprogs be removed from the base group (not from [core]).
I
Am Sonntag 01 August 2010 schrieb Dieter Plaetinck: think that nilfs-utils should be moved to the base group. I think there could be some other file system tools think this explanation makes sense. I just found this back:
So indeed, it seems like the goal is to remove all non-essential things (reiserfs, xfs, ..) from base.
They probably should be automatically installed if a
formatted with one of these filesystems by AIF. But usually
are using these filesystems know what they are doing and know
they have to select these packages for installation.
Actually it's fairly trivial to "preselect" those packagas based on the filesystems used during the filesystem step. I believe some of it is already implemented in aif.
Dieter My 2 cents about nilfs, I have added it to archboot environment some time ago. To integrate it into an installer it is
http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup partition is people who that plain not usable, because the kernel doesn't know it. All usual filesystem utilities like blkid etc. don't recognize it. Sure it will be an optional filesystem in the future, but it should be supported by the kernel and major filesystem and core utiltities in a sane way. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sun, Aug 1, 2010 at 10:30 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
On Sun, 1 Aug 2010 16:46:33 +0200
Heiko Baums <lists@baums-on-web.de> wrote:
I don't
agree with moving it to [core] but not to base, because base is assumed to be installed on every computer and packages in the base group are usually not listed in the depends array of a PKGBUILD.
On the contrary I
like jfsutils, lvm2 and xfsprogs be removed from the base group (not from [core]).
I
Am Sonntag 01 August 2010 schrieb Dieter Plaetinck: think that nilfs-utils should be moved to the base group. I think there could be some other file system tools think this explanation makes sense. I just found this back:
So indeed, it seems like the goal is to remove all non-essential things (reiserfs, xfs, ..) from base.
They probably should be automatically installed if a
formatted with one of these filesystems by AIF. But usually
are using these filesystems know what they are doing and know
they have to select these packages for installation.
Actually it's fairly trivial to "preselect" those packagas based on the filesystems used during the filesystem step. I believe some of it is already implemented in aif.
Dieter My 2 cents about nilfs, I have added it to archboot environment some time ago. To integrate it into an installer it is
http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup partition is people who that plain not usable, because the kernel doesn't know it. All usual filesystem utilities like blkid etc. don't recognize it. Sure it will be an optional filesystem in the future, but it should be supported by the kernel and major filesystem and core utiltities in a sane way.
Except that I've seen it running on his root partition on a booting laptop without any of these problems you speak of... -Dan
On Sun, Aug 1, 2010 at 10:30 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Sonntag 01 August 2010 schrieb Dieter Plaetinck:
On Sun, 1 Aug 2010
16:46:33 +0200
Heiko Baums <lists@baums-on-web.de> wrote:
I don't
Am Sonntag 01 August 2010 schrieb Dan McGee: think that nilfs-utils should be moved to the base group. I
agree with
moving it to [core] but not to base, because base is
assumed to be
installed on every computer and packages in the base
group are usually
not listed in the depends array of a PKGBUILD.
On the contrary I
think there could be some other file system tools
like jfsutils, lvm2
and xfsprogs be removed from the base group (not
from
[core]).
I
think this explanation makes sense. I just found this back:
http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup
So
indeed, it
seems like the goal is to remove all non-essential
things
(reiserfs, xfs,
..) from base.
They
probably should be automatically installed if a
partition is
formatted with one of these filesystems by AIF. But usually
people who
are using these filesystems know what they are doing
and know
that
they have to select these packages for
installation.
Actually
it's fairly trivial to "preselect" those packagas based on the
filesystems
used during the filesystem step. I believe some of it is
already
implemented in aif.
Dieter
My 2 cents about nilfs,
archboot environment some time ago. To integrate it into an installer it is plain not usable, because the kernel doesn't know it. All usual filesystem utilities like blkid etc. don't recognize it. Sure it will be an optional filesystem in
I have added it to the future, but it should be supported by the kernel and
major filesystem and core utiltities in a sane way.
Except that I've seen it running on his root partition on a booting laptop without any of these problems you speak of...
-Dan Yes sure i believe it works, my concerns are more that the main tools just don't support it, which makes it imho more complicated to implement the installation support.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Yes sure i believe it works, my concerns are more that the main tools just don't support it, which makes it imho more complicated to implement the installation support.
So here is what I needed to mess with to get it working: Kernel: "Version 2 of the filesystem, known as NILFS2, is included in Linux kernel 2.6.30." Works out of the box with the most recent arch kernel. mkinitcpio.conf: I just added: MODULES="nilfs2" I wonder if this is something that can be easily added to the filesystems hook. /boot/grub/menu.lst: kernel /vmlinuz26 root=/dev/sda3 ro rootfstype=nilfs2 AIF would need to take this into account, but seems easy enough. Initscripts: I provided a patch here: http://bugs.archlinux.org/task/20260 No other troubles as far as I know. Is there anything I'm missing? Let me know where I can help, this is an awesome filesystem. Blazing fast and when I delete or overwrite things on accident, it's so cool to just mount a snapshot from like an hour ago without having to set anything up in advance, and without even unmounting my root fs. Cheers, Alex
Am Montag 02 August 2010 schrieb Alex Matviychuk:
Yes sure i believe it works, my concerns are more that the main tools just don't support it, which makes it imho more complicated to implement the installation support.
So here is what I needed to mess with to get it working:
"Version 2 of the filesystem, known as NILFS2, is included in Linux kernel 2.6.30." Works out of the box with the most recent arch kernel.
mkinitcpio.conf: I just added: MODULES="nilfs2" I wonder if
Kernel: this is something that can be easily added to the filesystems
hook.
kernel /vmlinuz26 root=/dev/sda3 ro rootfstype=nilfs2 AIF would need to take this into account, but seems easy enough.
Initscripts: I provided a patch here: http://bugs.archlinux.org/task/20260
No other troubles as far as I know. Is there anything I'm missing?
Let me know where I can help, this is an awesome filesystem. Blazing fast and when I delete or overwrite
/boot/grub/menu.lst: things on accident, it's so cool
to just mount a snapshot from like an hour ago without having to set anything up in advance, and without even unmounting my root fs.
Cheers, Alex According to the util-linux git it seems new version will have nilfs2 support, if this happens archboot support will happen very soon.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sun, 1 Aug 2010 16:58:00 +0200, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Sun, 1 Aug 2010 16:46:33 +0200 Heiko Baums <lists@baums-on-web.de> wrote:
I don't think that nilfs-utils should be moved to the base group. I agree with moving it to [core] but not to base, because base is assumed to be installed on every computer and packages in the base group are usually not listed in the depends array of a PKGBUILD.
On the contrary I think there could be some other file system tools like jfsutils, lvm2 and xfsprogs be removed from the base group (not from [core]).
I think this explanation makes sense. I just found this back: http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup So indeed, it seems like the goal is to remove all non-essential things (reiserfs, xfs, ..) from base.
Just for information, the opposite point of view recently came up on the suckless mailing-list: http://lists.suckless.org/dev/1007/5256.html I prefer Arch's approach but it is probably true that a large base system reduces the workload of package maintainers. -- Pierre 'catwell' Chapuis
On Mon, 02 Aug 2010 15:31:47 +0200 Pierre Chapuis <catwell@archlinux.us> wrote:
On Sun, 1 Aug 2010 16:58:00 +0200, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Sun, 1 Aug 2010 16:46:33 +0200 Heiko Baums <lists@baums-on-web.de> wrote:
I don't think that nilfs-utils should be moved to the base group. I agree with moving it to [core] but not to base, because base is assumed to be installed on every computer and packages in the base group are usually not listed in the depends array of a PKGBUILD.
On the contrary I think there could be some other file system tools like jfsutils, lvm2 and xfsprogs be removed from the base group (not from [core]).
I think this explanation makes sense. I just found this back: http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup So indeed, it seems like the goal is to remove all non-essential things (reiserfs, xfs, ..) from base.
Just for information, the opposite point of view recently came up on the suckless mailing-list: http://lists.suckless.org/dev/1007/5256.html
I prefer Arch's approach but it is probably true that a large base system reduces the workload of package maintainers.
I don't think packaging becomes much harder when you remove optional filesystems and configuration tools from base. Dieter
Am Mon, 02 Aug 2010 15:31:47 +0200 schrieb Pierre Chapuis <catwell@archlinux.us>:
Just for information, the opposite point of view recently came up on the suckless mailing-list: http://lists.suckless.org/dev/1007/5256.html
I prefer Arch's approach but it is probably true that a large base system reduces the workload of package maintainers.
I don't know Source Mage, but I think that a large base system (as I understand this posting, all in one big package) has only disadvantages. It's far less flexible, wastes much more disk space for unneeded tools, makes a lot more work for the users and maintainers, because the base package - as I understand the posting - needs to be updated more often (a big package needs to be updated every time one small tool is updated), which forces the users to regularly download and the maintainers to regularly rebuild and upload a bigger package instead of sometimes down- and uploading a few much smaller packages, etc. Not really a good idea. Heiko
On Mon, 2 Aug 2010 18:08:50 +0200 Heiko Baums <lists@baums-on-web.de> wrote:
Am Mon, 02 Aug 2010 15:31:47 +0200 schrieb Pierre Chapuis <catwell@archlinux.us>:
Just for information, the opposite point of view recently came up on the suckless mailing-list: http://lists.suckless.org/dev/1007/5256.html
I prefer Arch's approach but it is probably true that a large base system reduces the workload of package maintainers.
I don't know Source Mage, but I think that a large base system (as I understand this posting, all in one big package) has only disadvantages. It's far less flexible, wastes much more disk space for unneeded tools, makes a lot more work for the users and maintainers, because the base package - as I understand the posting - needs to be updated more often (a big package needs to be updated every time one small tool is updated), which forces the users to regularly download and the maintainers to regularly rebuild and upload a bigger package instead of sometimes down- and uploading a few much smaller packages, etc.
Not really a good idea.
Heiko
I think they mean keeping regular packages like usual, but just making more packages part of the base group. And like I said earlier, I don't see the point either. Dieter
Am Mon, 2 Aug 2010 18:10:22 +0200 schrieb Dieter Plaetinck <dieter@plaetinck.be>:
I think they mean keeping regular packages like usual, but just making more packages part of the base group. And like I said earlier, I don't see the point either.
This indeed doesn't make much sense, too. I totally agree with you. Heiko
participants (6)
-
Alex Matviychuk
-
Dan McGee
-
Dieter Plaetinck
-
Heiko Baums
-
Pierre Chapuis
-
Tobias Powalowski