Quantcast

Storage

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Storage

Samba - linux mailing list
Hello all,
We have many servers at work laid out with a normally partitioned OS drive
supporting filesystems and one or more partitioned drives supporting
everything else on a large logical volume.
So if you're building a virtual server, why would you embrace the risk and
annoyance of resizing a partition table, compared with allocating the raw
disk (with offset) as an LVM pv?
If allocated without a partition table, extending filesystems is quick and
nearly risk free.

By the way, I am aware that just adding another disk is also quite easy,
and so this is more a question of opinion or good practice, rather than a
witch hunt.

Thanks,
David
--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Storage

Samba - linux mailing list
On 07/05/17 08:08, David C via linux wrote:
> Hello all,
> We have many servers at work laid out with a normally partitioned OS drive
> supporting filesystems and one or more partitioned drives supporting
> everything else on a large logical volume.
> So if you're building a virtual server, why would you embrace the risk and
> annoyance of resizing a partition table, compared with allocating the raw
> disk (with offset) as an LVM pv?
> If allocated without a partition table, extending filesystems is quick and
> nearly risk free.

I agree.  I always use LVM to allocate storage, because of its flexibility.

With LVM thin provisioning you can also 'overcommit' your disk, which means
that as long as every VM doesn't fill its disk at the same time, you can
allocate more space to VMs than you have physical storage.  So a hundred 10G
VMs can exist on a 500GB disk rather than taking a terabyte.  It's exactly the
same as overcommitting memory.  But that's a risk you want to think about
before you go into it.  It's also much easier to thin provision LVs as clones
of existing disks, which make it easier to spin up and tear down short lived
VMs for e.g. testing.

I tend to think of layering LVM on top of MD RAID1 or RAID10.  I found out the
other day that MD's implementation of RAID10 can read from all disks in
parallel, where RAID0 on RAID1 only reads from half of the disks.  It
functions exactly the same for everything else, so that's pretty cool.

Have fun,

Paul

--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Storage

Samba - linux mailing list
In reply to this post by Samba - linux mailing list
    Does any one have any useful comments to make on David's question?
"Which is better, resizing a partition or using LVM?"

I don't know the answer, and I guess that would vary depending on the
configuration of the hardware/systems being used.

From my limited experience LVM is a rock solid, industry tested, and
proven solution that is used in both Unix and Linux. I have never had
the opportunity to run data performance related tests on any such
infrastructure.

However from my perspective, I am usually working with very low spec
hardware, trying to milk the most out of it, and whether true or false
(likely false until proven otherwise), I have the assumption that any
abstraction from physical hardware will cause decreased performance,
and potential for instability, and thus I try to stay as close as
possible to bare metal. But is this a false belief ?

Could fragmentation be an issue if you use too many LVM extents, and
does resizing a partition extend contiguous space or can it also
create fragmentation?

Personally I usually mount data from separate disks (virtual or
physical) so that I can replace a disk with a larger disk when
necessary, and so I have not bothered with LVM or resizing of
partitions.

George



At Sunday, 07-05-2017 on 08:08 David C via linux wrote:


Hello all,
We have many servers at work laid out with a normally partitioned OS
drive
supporting filesystems and one or more partitioned drives supporting
everything else on a large logical volume.
So if you're building a virtual server, why would you embrace the risk
and
annoyance of resizing a partition table, compared with allocating the
raw
disk (with offset) as an LVM pv?
If allocated without a partition table, extending filesystems is quick
and
nearly risk free.

By the way, I am aware that just adding another disk is also quite
easy,
and so this is more a question of opinion or good practice, rather
than a
witch hunt.

Thanks,
David
--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux

 

At Sunday, 07-05-2017 on 08:08 David C via linux wrote:


Hello all,
We have many servers at work laid out with a normally partitioned OS
drive
supporting filesystems and one or more partitioned drives supporting
everything else on a large logical volume.
So if you're building a virtual server, why would you embrace the risk
and
annoyance of resizing a partition table, compared with allocating the
raw
disk (with offset) as an LVM pv?
If allocated without a partition table, extending filesystems is quick
and
nearly risk free.

By the way, I am aware that just adding another disk is also quite
easy,
and so this is more a question of opinion or good practice, rather
than a
witch hunt.

Thanks,
David
--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux


--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CentOS 7 and Xfce

Samba - linux mailing list
    Hi,

If anyone has experience installing Xfce on CentOS 7, I have
experienced a few issues.

I have searched on the Internet, and I am currently doing further
tests, but if someone has already found a solution, please let me
know.

When installing XFCE in CentOS 7 the installation appears to be
missing a number of components of Xfce.

Missing are;

1) NetworkManager Applet

2) Date and Time Applet

3) Audio Mixer

4) Mousepad

5) Kiwi (and a number of other) themes

There is likely to be other items also missing, the above were just
the first that I found to be missing.

Sadly CentOS 7 appears to be very much built to support only Gnome or
KDE, neither of which I particularity like (and are a bit heavy on
resources for a VDI solution).

https://www.rootusers.com/how-to-install-xfce-gui-in-centos-7-linux/
yum install epel-release -y
yum groupinstall "Xfce" -y







--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CentOS 7 and Xfce

Samba - linux mailing list
I know this is not quite what you're after, but Korora linux has an ISO
with XFCE available out of the box:

https://kororaproject.org/download

It's not Centos, but it's quite similar.

--
MC
--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CentOS 7 and Xfce, and Korora Live Xfce 25

Samba - linux mailing list
    Mike,

Thanks for that tip! I am downloading Korora Live Xfce 25 now. 

I will post back about how it runs in my test environment once I have
had chance to try it out.

You may never understand why I like Xfce (not sure I do either), I
just find it simple, clean but functional, click and point menu style
interface very attractive. Esthetically pleasing.

Regards,

George Kirkham.


At Tuesday, 09-05-2017 on 08:11 Mike Carden via linux wrote:


I know this is not quite what you're after, but Korora linux has an
ISO
with XFCE available out of the box:

https://kororaproject.org/download

It's not Centos, but it's quite similar.

--
MC
--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux


--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Loading...