PDA

View Full Version : SLES 12 SP3 filesystem on /dev/sdX is supported or partitions required



sharfuddin
31-Jan-2018, 14:42
disk /dev/sdb is a LUN that could be extended if and when needed from Storage(SAN).

1 - created a file system on /dev/sdb(without creating partition)

mkfs.xfs -m crc=1 /dev/sdb

2 - mount the file system

3 - while the file system was mounted, extend the LUN(/dev/sdb) from Storage

4 - new disk size appeared when running
lsblk or
fdisk -l /dev/sdb

5 - ran
xfs_growfs /dev/sdb

Questions:
a) should I rather use lvm ? any advantage that I am missing ?
b) is it supported by SUSE to create file systems directly on LUN(as I did).. I am asking this because Yast does not allow to create file system directly on the disk(without first creating partition)

ab
31-Jan-2018, 15:39
On 01/31/2018 06:44 AM, sharfuddin wrote:
> Questions:
> a) should I rather use lvm ?
> b) is it supported by SUSE to create file systems directly on LUN(as I
> did).. I am asking this because Yast does not allow to create file
> system directly on the disk(without first creating partition)

This has come up in the past, but I do not remember where. I believe (but
do not know) that this is supported, but you are correct in that Yast will
not let you do it. LVM is a great way to to have flexible filesystems,
and I would use it over a partition-less disk because then you get Yast
support and no questions otherwise on supportability, but that's just me.
I believe all of your commands would work in an LVM setup, though you
would need an extra command to extend the physical volume, or else add a
physical volume and then add it to your volume group, and grow your
logical volume.

I also use LVM because it means I can encrypt everything if I need for
boxes that need full-disk encryption.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

ThalLimited
01-Feb-2018, 12:54
I opened an SR# 101144860381 and here is what they said:


I would say that if you use it for the roo file system, I would suggest to reinstall. Now if it is file sytem for storage use, you can leave such as.

ab
06-Feb-2018, 16:10
I think you should push back for an official stance, since the
documentation seems to contradict them; on the other hand, now that
they've said, as a representative of the company, that it is supported in
some cases, you could potentially hold them to that fire, at least until
somebody points out that the documentation correctly trumps people's opinions:

https://www.suse.com/documentation/sles-12/singlehtml/stor_admin/stor_admin.html#sec.lvm.vg



Using an unpartitioned disk is not supported by SUSE Linux Enterprise
Server. Thus we discourage you from using unpartitioned disks even though
LVM can handle that solution.


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

jmozdzen
09-Feb-2018, 16:19
Hi,


Questions:
a) should I rather use lvm ? any advantage that I am missing ?
b) is it supported by SUSE to create file systems directly on LUN(as I did).. I am asking this because Yast does not allow to create file system directly on the disk(without first creating partition)

a) Yes, I strongly advise to use LVM (and to put the PV into a partition, see answer to "b)"). LVM will give you the flexibility to i.e. live migrate to a different PV without bringing down the server, i.e. if the SAN system needs replacement. *Very* convenient, indeed. On top, you get all the flexibility to sub-divide that disk space, to move on to some extra redundancy (mirrored LVs) and generally stay more flexible.

b) I recommend to *always* partition the disk. It is surprising how years later you may get haunted by some weird situation that will rely on that extra space between the partition table and the first (aligned) partition. Not to forget that system-level tools may get confused if the content of the first block, especially the "signature", is different from what to usually expect.

That said, in the early days I had many systems set up to work without partitioning on additional disks... in those days, disk space was scarce and expensive. It did work, and besides above situations, I've not come across any major problems.

Regards,
J