:: Re: [DNG] /usr to merge or not to m…
Pàgina inicial
Delete this message
Reply to this message
Autor: Alessandro Selli
Data:  
A: dng
Assumpte: Re: [DNG] /usr to merge or not to merge... that is the question
On 28/11/18 at 11:37, Didier Kryn wrote

:
> Le 28/11/2018 à 10:35, Rick Moen a écrit :
>> Quoting Didier Kryn (kryn@???):



[...]

>     Hi Rick.
>
>     It seems to me you're fighting to get the last bit of performance
> out of mechanical hard drives, including by using different
> filesystems for different partitions, which makes a lot of sense for
> servers. I agree that filesystem play a major role in performance and
> safety. For the performance of the disks, and considering you speak of
> servers, you ommit to speak of the RAID configuration, which seems to
> me more important than the location of the partitions.


  Different mount options for different parts of the Unix filesystem 
apply also to RAID and LVM metadevices/device-mapper backed
filesystems, too.


>     For what concerns, laptops, I think we are in the era of ssd and,
> unfortunately, there is usually only one disk drive per laptop, except
> of older ones where the cdrom drive can be replaced by a disk.



  So what?  What's wrong in securing the filesystem and optimizing it's
performance even on SSDs, even on laptops, even when one has only one
storage device?
Besides, an increasing number of people give up on the DVD unit to make room for a second HD/SSD installed with an adaptor.

>     Today, servers are probably still the domain of RAIDs based on
> mechanical hard drives, laptops, the domain of ssds, and desktops are
> the place where both live together - I have one desktop like this.



  Server's peculiarities do deserve to be taken into consideration by a soi-disant universal OS. IIRC Debian is used a lot on servers.
  Why do you think ro, nodev, barrier, sync and other mount options do no make sense on a RAID/LVM filesystem?


--
Alessandro Selli <alessandroselli@???>
VOIP SIP: dhatarattha@???
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE