Anton Aylward wrote:
That will show you modules that you should
build into your kernel as they are drivers for _your_
machine's hardware, though not all of them are needed for
boot. For example, probably don't need network to boot unless
you boot from net.
If I'm not booting from the net then I cant see why I should.
What exception are you thinking of?
It's the exception that I'm *not* thinking of
that I was thinking of ... :-)
"lsmod", will show you what modules
have been dynamically loaded,
while "ls /sys/module" will show you all modules the kernel
has builtin OR dynamically loaded.
I (still) can't see where the ext driver is,
Why do you think you have it loaded? I don't have it loaded
in my kernel.
but I do note that BtrFS
requires a few other modules like XOR and raid6_pq. More incentive to go for a
ext4 RootFS, eh?
xfs anyone? :-)
> For example, I have
> everything except /boot and SWAP on LVM. That includes the ROOTFS. So the LVM
> modules needs to be included in initrd.
Yes, the initrd becomes bigger.
Yes, but I absolutely need LVM.
Do you need your rootfs to be LVM?
I am @#$$%$#@ sick and tired of having the RootFS grow and having to take down
the disk and shuffle partitions around.
I've yet to resize my root since I got it:
xfs_admin -u /dev/sdc1
July 18, 2009 at 15:57:47.354
I made root 12G (currently using half). (/usr /var
/usr/share, /home and /var/cache/squid are all separate
in addition to other local filesystems).
Having /usr as part of the RootFS is ... not nice.
It complicates provisioning.
12G root is about half full.
I think if I could have /usr on a separate FS as of old and this
whole stillness of where the binaries live sorted out, then yes my
RootFS would be a LOT smaller.
But I don't want to follow your approach; I want to have
a system that follows an upgrade path as delivered.
If you have an initrd, having a separate /usr is
If you want to boot directly from disk, as suggested
by systemd docs, for speed, you aren't suse supported.
I wanted to
complexity involved in booting root. I also
wanted to constrain it at the start of the disk to limit
seeks for reading the root files, so it is the 1st
partition with only the 1st half of the disk used
for content (short-stroking), also to limit seek
latency on 15K SAS disks.
It was all quite pointless. Every optimization was promptly
outclassed by and advance in the disk technology.
Disks are advertised w/an average latency -- w/
15K SAS drives usually averaging under 10ms. 2ms of
that is for rotational position on average, rest is
inner/outer seeks. If you cut the max track in half, the
inner/outer number goes to less than half (because more
tracks are are in outer rings which are track 0).
In rotating media, such concerns are still valid and
are separate from SW optimizations. Of course one could
consider SSD's which have no positional seek, but the do have
some positioning latency that is helped by occasional
defragmenting, I've noticed.
Now we have SSDs that are dirt cheap. My core system,
that is without /home
(and all my photographs) and the web stuff on /srv (not the least of which is
ownCloud for my home WLAN and mobile devices) will fit on a 60G pci-e insert
that I can get for less than router cost. Check eBay for example.
If I omit /srv and the ~anton/Photographs and ~anton/Movies and ~anton/music
then everything including /usr/share can fit, comfortably, on a 120G SSD.
I might just do that some time next year. Santa didn't deliver on the SSD :-(
So the kind of optimization you talk about becomes irrelevant.
It was relevant in 2009, and still is for my system, since
it is on the same system my /home is on. My data disks wouldn't
fit on an SSD (about 24T for data and 12T dedicated to backup,
each of which is running RAID10). Your 120G wouldn't go far
if holding video (my living room computer runs Win7 and feeds
my video screen, but the content is on my linux machine in a
My home system has to live by the whim of my free time
and what's left over
after mortgage and food; you're in a commercial setting. You can probably make
budget submission :-) Goodluck!
My figures are for my home system.
And in this day and age when openSuse ships with systemd, you have to maintain that by
hand. Something I'm not willing to do.
It's mostly automated with continuing development as something
[Big snip about using stuff in /etc/rc.d etc etc which
I grew up with and to be
honest am glad is past. I much prefer systemd.]
You have a user-system. Sd was focused on that.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org