Le Fri, 12 Jan 2018 13:32:49 +0000
Wols Lists <antlists@xxxxxxxxxxxxxxx> écrivait:
> On 11/01/18 03:07, Dave Chinner wrote:
> > XFS comes from a different background - high performance, high
> > reliability and hardware RAID storage. Think hundreds of drives in a
> > filesystem, not a handful. i.e. The XFS world is largely enterprise
> > and HPC storage, not small DIY solutions for a home or back-room
> > office. We live in a different world, and MD rarely enters mine.
>
> So what happens when the hardware raid structure changes?
hardware RAID controllers don't expose RAID structure to the software.
So As far as XFS knows, a hardware RAID is just a very large disk.
That's when using stripe unit and stripe width options make sense in
mkfs_xfs.
> Ext allows you to grow a filesystem. Btrfs allows you to grow a
> filesystem. Reiser allows you to grow a file system. Can you add more
> disks to XFS and grow the filesystem?
Of course. xfs_growfs is your friend. Worked with online filesystems
many years before that functionality came to other filesystems.
> My point is that all this causes geometries to change, and ext and
> btrfs amongst others can clearly handle this. Can XFS?
Neither XFS, ext4 or btrfs can handle this. That's why Dave mentioned
the fact that growing your RAID is almost always the wrong solution.
A much better solution is to add a new array and use LVM to aggregate
it with the existing ones.
Basically growing an array then the filesystem on it generally works
OK, BUT it may kill performance (or not). YMMV. At least, you *probably
won't* get the performance gain that the difference of stripe width
would permit when starting anew.
> Because if it can, it seems to me the obvious solution to changing
> raid geometries is that you need to grow the filesystem, and get that
> to adjust its geometries.
Unfortunately that's nigh impossible. No filesystem in existence does
that. The closest thing is ZFS ability to dynamically change stripe
sizes, but when you extend a ZFS zpool it doesn't rebalance existing
files and data (and offers absolutely no way to do it). Sorry, no pony.
> Bear in mind, SUSE has now adopted XFS as the default filesystem for
> partitions other than /. This means you are going to get a lot of
> "hobbyist" systems running XFS on top of MD and LVM. Are you telling
> me that XFS is actually very badly suited to be a default filesystem
> for SUSE?
Doesn't seem so. In fact XFS is less permissive than other filesystems,
and it's a *darn good thing* IMO. It's better having frightening error
messages "XFS force shutdown" than corrupted data, isn't it?
> What concerns me here is, not having a clue how LVM handles changing
> partition sizes, what effect this will have on filesystems ... The
> problem is the Unix philosophy of "do one thing and do it well".
> Sometimes that's just not practical.
LVM volumes changes are propagated to upper levels.
If you don't like Unix principles, use Windows then :)
> The Unix philosophy says "leave
> partition management to lvm, leave redundancy to md, leave the files
> to the filesystem, ..." and then the filesystem comes along and says
> "hey, I can't do my job very well, if I don't have a clue about the
> physical disk layout". It's a hard circle to square ... :-)
Yeah, that was apparently the very same thinking that brought us ZFS.
> (Anecdotes about btrfs are that it's made a right pigs ear of trying
> to do everything itself.)
>
Not so sure. Btrfs is excellent, taking into account how little love it
received for many years at Oracle.
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@xxxxxxxxxxxxxx>
| +33 1 78 94 84 02
------------------------------------------------------------------------
Attachment:
pgpNw8joBR2vG.pgp
Description: Signature digitale OpenPGP
