Beiträge von vomov

I've got 8GB, and I'm seeing RAM sitting on 4% idle, and occacional jumps to 12% on access, so I *guess* it should be okay for my usage pattern to go to 2GB RAM. I've no idea how XFS behaves under different usage patterns, and no idea how it behaves under low free memory conditions, though. Other than simply trying it out, I'm not sure how to figure out what the result will be.

The jbd in the offending processes stands for 'Journaling Block Device', and it is something associated with EXT4. just Google 'jbd2', and the first page will be dominated by the issue we're experiencing.

What file system are you using? I switched from EXT4 to XFS for exactly that reason.

Zitat von Reed

You can use this method to detect what is accessing the disk:
My Guide to Debugging Disk Spin-ups

Ooh, nice! I'll make use of that in the future, thanks!

Couchpotato shouldn't be an issue; it periodically checks the servers, and only checks the disks on invervals if it's expecting something (I think it even monitors downloads, but I'm not sure).

Late reply, I was on vacation

I found that here, under 'Samba'. I applied some of the tips on that page, but not all.

Something like that, yes. If I understand correctly, samba stores some data about the share on the drive itself which causes almost continuous access, preventing spindown under certain circumstances. I'd have to check what I changed exactly, but it comes down to that.

I've given my devices (PC, drag-around-tablet) fixed IP's, and set up a range. It's not too limited for my uses! Thanks for your help!

I've set up a rule (based on 'reject', with ! before the ip-adress), which works well; my PC can access OMV, other devices can't. At the same time, other traffic is unimpeded.The content on the thread you posted is quite helpful, thanks!
Question: is it possible to put something that behaves like an 'OR' in the source (Let's say 192.168.68 to .76 require access, as well as .81, while other IP's are to)?

Perhaps this is only as a reference, and not a real thread, but still; I've got some progress.

Yesterday, I reformatted another drive as XFS, which spun down exactly ten minutes after I stopped messing with it. And it stayed down!

So, I repeated the process, and moved the third drive to XFS this morning. It also spun down after ten minutes!
And then I accessed it through windows, copied a handful of files, and waited ten minutes. Still spinning. About an hour later, it finally spun down, so it would seem I only found one issue.

Luckily, I had one more thing to try; set the sharing to go through NFS, instead of SMB. My reasoning was that SMB might not be properly aware of disconnects, and therefore keep the drive active (no idea how I got there, though)
I'd read NFS was considered superior anyways, and android (including the media centre) natively support it, so why not?

And now, FINALLY, everything spins down properly. The last EXT4 drive (not the OS drive) still seems to have some issues going down and staying down (two issues), but I'll move that one to XFS later. SMB also seemed to interfere somehow, so NFS is a bit more desired (detail: I'm also seeing about 20% increase in transfer speeds on LAN after switching to NFS).

Ah; I forgot OMV had a built-in firewall. I'll go mess with that for a bit, thanks!

I only access it through the local network, so that should be fine.
But upon reading the guide you posted, I might try to set up that. Thanks!

Okay, I've also disabled system monitoring, rsyslog, cron, ntp, and rsync. No effect.
I also changed a hard drive (a 1TB Seagate piece of excrement to a 3TB WD Red), which I formatted as XFS. Initally, I set it to spin down, to see if it made a difference. It did indeed spin down, but since WD Red are designed to keep active all the time, I set it to 'happily spinning all the time'. I'm slowly copying stuff to the WD Red to free up another drive, so I can format that one as XFS.

I've been having issues with OMV, and in hunting down the cause, I've been needing to use SSH quite a bit. When the issue appears, I enable SSH, connect with an android version of putty, and figure out what's going on.
Enabling SSH every time is taking quite a bit of time, so I'm looking for a method where I can leave it on, without any security risk. Is there a way to set SSH to only respond to a specific mac address?

I've got an odd little OMV setup, with four HDD's.
Primarily, I've got an SSD, on which OMV lives, as well as the main download folders and such.
Next to that, I've got three HDD's, with different use cases. One is used perhaps twice a day, one is used once every couple of days, one is updated once a week (Friday backups).

The SSD is set to stay active at all times, but I'm not sure if this has any effect (it's an SSD, after all). All others are set to spin down after fifteen minutes, with the acoustic setting set to 'quiet, low performance'.

I've no problems with performance; everything works as intended. However, the disks don't always spin down. Right now, all three are active, and I do not know why. Sometimes all three are inactive, sometimes one starts up in the middle of the night and won't go back to sleep.

Is there another way to check if there are processes blocking them from spinning down?
Ideally, I would also love a logfile stating WHY disks spin up, but I'll settle for something that tells me why they don't spin down.

UPDATE:
What I've found out and messed with so far)

• Flipped acoustic power management to 'disabled'. Not sure what this does, exactly, but the sound seems the same, and power usage is either the same, or not different enough to be measured accurately.
• I've set commit to 60 in fstab. The audible click every five seconds is down to every minute or so, but the disks still don't spin down.
• I've addeed noatime to fstab. No effect.
• changed /etc/init.d/samba to work from ram, and not from a location on the hard drive in question.
• Got inotify-tools, and tried to use inotifywatch to figure out what happens. Not seeing a lot of actual activity, though.
• iotop tells me transmission jumps on the SSD during download, and a whole lot of other processes. It would seem the journaling process is active and doing IO, albeit a very small amount. Might this block spin down? I've got EXT4 for all drives, and there have been issues with the journaling blocking spin down...
• Used lsof | grep sd# (# as the hard drive identification), which tells me on all disks there are three commands running: all three named jbd2/sd#. They look like this:

root@cardboardbox:~# lsof | grep sda
COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME # pasted for easy reading
jbd2/sda1 1929                     root  cwd       DIR               8,33     4096          2 /
jbd2/sda1 1929                     root  rtd       DIR               8,33     4096          2 /
jbd2/sda1 1929                     root  txt   unknown                                        /proc/1929/exe
^C
root@cardboardbox:~# lsof | grep sdb
jbd2/sdb1 1931                     root  cwd       DIR               8,33     4096          2 /
jbd2/sdb1 1931                     root  rtd       DIR               8,33     4096          2 /
jbd2/sdb1 1931                     root  txt   unknown                                        /proc/1931/exe
^C
root@cardboardbox:~# lsof | grep sdd
jbd2/sdd1 1933                     root  cwd       DIR               8,33     4096          2 /
jbd2/sdd1 1933                     root  rtd       DIR               8,33     4096          2 /
jbd2/sdd1 1933                     root  txt   unknown                                        /proc/1933/exe
^C
root@cardboardbox:~# lsof | grep sdc
jbd2/sdc1  342                     root  cwd       DIR               8,33     4096          2 /
jbd2/sdc1  342                     root  rtd       DIR               8,33     4096          2 /
jbd2/sdc1  342                     root  txt   unknown                                        /proc/342/exe
^C

Is this indeed due to the EXT4 journaling, or should I keep looking?
If yes: is there some form of fix, aside from moving everything over to XFS?
If no: how do I keep looking? I've not enough knowledge to know further steps

So it's kinda like 'standard included drivers' in Windows? Seems unnecessary, but if they're harmless, I'll remove them from the list by installing. Thanks!

I've been seeing something odd in my OMV; in the update manager there are a lot of entries relating to network cards. I've got a built-in realtek (I think), and a mpcie wifi card (intel something, not used), but there are entries for broadcom, marvell, myricom and qlogic. I've updated the ones for realtek and intel (both had multiple entries), and nothing seems to have gone horribly wrong.

Is this normal? Should I install these, or ignore them?

So far, still working. I'm starting to think one of my bios settings was creating the problem, but I'll be extra wary for this problem reappearing in the next few days...

Zitat von davidh2k

... copy it via PuTTY? apt-get update && apt-get upgrade -s

Ran the command through putty, which returned quite a list. I've put the output in an attachement.

I've installled the backports kernel via OMV-extras (3.16, it says), and get a quite extensive list of additional updates, including a set for the processor and LAN. Since windows XP, I've developed a slight resistance towards updating, and it all does seem to be working fine... Should I update anyway?

I've just reinstalled and put everything back the way I want it (loosely), and have quickly made a logfile using the method provided (id: 6SSn7IlI), as a 'baseline'.
I did mess around in the bios, and disabled some settings (like intel speedstep), and have not enabled SSH. Now, I'll wait and see what happens.

subzero79: My mainboard is a Asrock Q1900-ITX, and I have no external USB hubs. Except for the hard drives, LAN, and the power-connector, there's nothing connected to the box.

Minor detail: I've not updated anything, nor installed the backports kernel. Should I?