plugout.net

(LaCie-CloudBox 2TB - fvdw-sl 15.3)

Good day.

Converted my stock CB a few days ago and I'm very satisfied with the results -- for the most part.

Have been reviewing the NAS' internals and noticed a few anomalies.

(Just one per thread, or nothing would get answered.)

When checking running processes with "ps auxww," noticed a few daemons that (I believe) are of no use to CB, and are probably vestigial from a prior version of the firmware. Because of limited RAM and a slow processor, I would like to eliminate any extraneous processes.

The offending daemons are (I'm sure I missed one or two others):

[code]
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 299 0.0 0.0 0 0 ? S 07:05 0:00 [jfsIO]
root 300 0.0 0.0 0 0 ? S 07:05 0:00 [jfsCommit]
root 301 0.0 0.0 0 0 ? S 07:05 0:00 [jfsSync]
root 302 0.0 0.0 0 0 ? S< 07:05 0:00 [xfsalloc]
root 303 0.0 0.0 0 0 ? S< 07:05 0:00 [xfs_mru_cache]
root 304 0.0 0.0 0 0 ? S< 07:05 0:00 [xfslogd]
root 504 0.0 0.0 0 0 ? S< 07:05 0:00 [raid5wq]
[/code]

As far as I Know CB uses neither the jfs nor the xfs file systems and there is no RAID.

Is there a way to disable them permanently?

Thank you.

Hi Auroro,

these JFS/XFS kernel processes are not modular so you can not unload them.

To remove them, the kernel should be compiled again...

Do you note that they use 0% CPU and 0%MEM :whistle

we use one kernel for all kirkwood based lacie devices (also the multi disks ones like 2big2 and 5big2) .
As a result means the kernel setup contains indeed some features that are not useful for all these device, but they don't influence performance as they are not consuming any cpu time as Jock also mentioned. The total kernel is about 3 MB so it consumes only small amount of the RAM. I could make it smaller by making a dedicated kernel for each device but I do not see that that would serve any useful purpose.

Thank you for you quick reply, Jocko.

Your answer really begs the question, though.

Since CloudBox has its own separate kernel and CB doesn't use the jfs or xfs file systems, why were they compiled into the kernel in the first place?

Shouldn't a kernel dedicated to a specific machine with limited resources be as lean as possible?

Thank you, again.

:-D I explained you in the post above your last post why we use one kernel for all arm kirkwood based devices. Some devices need more features, some less. But making dedicated kernels is just extra work and could cause errors. One kernel that suites all is better and easier.
Indeed on the moment jfs and xfs are not used standard in the firmware and could be left out but but some experienced users requested for it in the past. So we included them. For example the 5big2 can take 5 disk some user might want to use xfs partitions as data partitions.
Of course they could also be be supplied as module but it is easier to include those in the kernel.
The cloudbox has 256 MB of ram. If I would minimize the kernel it would save about 0.75 MB in RAM usage. What is the issue ?
As said they don't consume any cpu time if not in use.

Hello, fvdw.

Somehow, I missed your prior post and only read Jocko's.

I can appreciate from the developer's point of view how one size fits all makes sense. Apparently, LaCie does the same, but not as well, given its firmware hodgepodge of RAID and LVM for a one disk NAS.

If and when I have time, I'll review the kernel "config" file in /proc and may consider compiling my own kernel. I'm used to cross-compiling kernels and modules for a couple of tiny VPS instances I run remotely.

By the way, the purpose of my questions and comments is to gain knowledge about the firmware and, hopefully, to make suggestions that could improve it.

(Not trying to start a religious war, just expressing my opinion) I prefer the xfs file system and use it on all my Linux boxes, I consider it far superior to any of the ext* versions. However, xfs consumes a lot more resources than any of them. Hence, I'm afraid that if used on the data partition of the CB, overall performance would be affected. Although I would welcome hearing to the contrary from someone who is actually using it.

Thank you for your great efforts with the firmware.

Auroro wrote:
If and when I have time, I'll review the kernel "config" file in /proc and may consider compiling my own kernel. I'm used to cross-compiling kernels and modules for a couple of tiny VPS instances I run remotely.

be aware that we use a patched kernel, using the standard ns2 setup in the vanilla kernel will not allow you to use some features, like accessing the flash memory and back side usb port

By the way, the purpose of my questions and comments is to gain knowledge about the firmware and, hopefully, to make suggestions that could improve it.

we would appreciate that, any input is welcome

(Not trying to start a religious war, just expressing my opinion) I prefer the xfs file system and use it on all my Linux boxes, I consider it far superior to any of the ext* versions. However, xfs consumes a lot more resources than any of them. Hence, I'm afraid that if used on the data partition of the CB, overall performance would be affected. Although I would welcome hearing to the contrary from someone who is actually using it.

I did try xfs once but here is no speed advantage, for the rest why would it be better or superior ? please explain.

Good day.

fvdw wrote:be aware that we use a patched kernel, using the standard ns2 setup in the vanilla kernel will not allow you to use some features, like accessing the flash memory and back side usb port

Thank you for confirming that, fdvw, I had guessed as much. Are the patches publicly available? If so, I would apply them before compiling the kernel (why re-invent the wheel). I'm just looking for as light weight a kernel as possible (such as I compile for a tiny remote VPS instance with 128 MiB of RAM).

Do your patches also include the patches that, presumably, allow the led to work as intended?

http://www.spinics.net/lists/arm-kernel/msg236696.html

By the way, my NAS is a LaCie-CloudBox 2TB and does not have a back USB port nor (I believe) flash memory. I guess that it shares the kernel with a ns2, though?

fvdw wrote:I did try xfs once but here is no speed advantage, for the rest why would it be better or superior ? please explain.

That's what I suspicioned with a low resource NAS -- it probably would be overkill.

For a desktop, especially with RAID0 or RAID10, XFS is very speedy and can be defragmented (yes, from the old DOS days). Also, crash recovery is quicker and it doesn't have to be fsck'd every so many days, a la ext*.

For a server under heavy load it's ideal.

I do greatly appreciate your time and effort, fvdw.

the cloudbox is a kirkwood device but has a totally different mainboard then the nwsp2, as such it needs its own kernel setup file