Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Ted Ts'o]

On Wed, Dec 21, 2011 at 02:32:58PM +0100, Goswin von Brederlow wrote:
> > If we want to improve fsck time then the best thing to do would be
> > to consider a different default value for the -i option of mke2fs.

This advice is not applicable for ext4, since it will not read unused
portions of the inode table.  There have been a number of improvements
in the ext4 file system format which means that in general fsck times
for ext4 are around 7-12 times faster than the equivalent ext3 file
system.

> > As an aside "mke2fs -t ext4" includes huge_file, dir_nlink, and
> > extra_isize while mke4fs doesn't.  This difference seems wrong to
> > me.
> 
> Urgs. +1.

I've never heard of "mke4fs" --- who thought up that abortion?

"mke2fs -t ext4" and "mkfs.ext4" will both do the right thing, as far
as creating file systems that have the correct ext4 file system
features for a file system designed to be mounted using the ext4 file
system driver in modern Linux kernels.

- Ted



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111227211736.ga10...@thunk.org

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Raphael Geissert]

Russell Coker wrote:

> On Thu, 22 Dec 2011, Goswin von Brederlow  wrote:
>> PS: I myself like a seperate /usr but I wouldn't use it for my parents.
>> I do want a seperate /var and /home for them though so they can't DOS
>> the system by filling up their home.
> 
> How would filling up /home DOS the system?

At least a couple of years ago if you left /home with no free space, kdm (or 
something under the hood) would be unable to create ~/.Xauthority-* files, 
making it impossible to log into a graphical session.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ef7f66a.8149b60a.7edb.a...@mx.google.com

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Goswin von Brederlow]

Russell Coker  writes:

> On Thu, 22 Dec 2011, Goswin von Brederlow  wrote:
>> PS: I myself like a seperate /usr but I wouldn't use it for my parents.
>> I do want a seperate /var and /home for them though so they can't DOS
>> the system by filling up their home.
>
> How would filling up /home DOS the system?

Filling /home doesn't but filling /var does. And if it is all one
partition ... Prior to recent changes this also affected /var/run and
/var/lock and so on. With /var being full you had problems booting.

> The only common program I can think of which fails hard when it runs out of 
> disk space is Squid.  I expect that some DB servers also have serious 
> problems 

No squid, no google or amazon anymore. Effectively (for the target
audience) DOSed.

> but I don't think that they will be running a DB server on their home 
> workstation.

If the system runs out of space it can't spool the mail telling me the
system is full. 

> My experience with systems I run for people who aren't computer experts 
> (which 
> includes my parents) is that filling /home causes various parts of their 
> desktop environment to cease working (thus effectively DOSing the system) and 
> they also just can't save files.
>
> I have a separate partition for /home on such workstations, but this is just 
> for ease of backups.

MfG
Goswin



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obv09alm.fsf@frosties.localnet

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Russell Coker]

On Thu, 22 Dec 2011, Goswin von Brederlow  wrote:
> Also / and /usr can be read-only and definetly should be on a systems
> likely to have power outages like laptops. And with a read-only
> partition you have neither fsck nor journal replay.

You don't have a fsck if the time/count for a fsck hasn't been met.  If you 
have mounted a filesystem ro every time but the 6 months (or whatever time 
period) has elapsed then you will get a fsck.  You could use tune2fs (or an 
equivalent for other filesystems) to make it an indefinite period.

As for power outages, last time I was using a Debian/Unstable laptop I noticed 
that ext2/3/4 filesystems were remounted with different timeouts according to 
the power state.  So it seems that we already have some better measures to 
avoid data loss in the event of power failure.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112220043.50594.russ...@coker.com.au

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Goswin von Brederlow]

Russell Coker  writes:

> On Sun, 18 Dec 2011, Josselin Mouette  wrote:
>> > Doing this has many advantage. Like, if your laptop has to unexpectedly
>> > reboot (like when you inadvertently removed power cord when batteries
>> > were not plugged, which happens often in real life), having separated
>> > partitions usually makes the fsck faster.
>> 
>> This is complete bullshit. With a journaled filesystem, the boot time
>> will greatly increase with the number of filesystems to check. If no
>> files were modified in /usr, they won’t be mentioned in the journal, and
>> that’s all. But having one journal to parse for all the system is
>> definitely a measurable improvement.
>
> If we want to improve fsck time then the best thing to do would be to 
> consider 
> a different default value for the -i option of mke2fs.
>
> The current default is to have one Inode per 16K of disk space.  Of the 
> Maildir format mail servers that I run the one with the smallest disk space 
> used per Inode has 307G and 4773821 Inodes in use for an average of 67K per 
> Inode.  A randomly selected Debian workstation with a lot of packages 
> installed has for it's root filesystem 9.1G and 19 Inodes for an average 
> of 49K.
>
> As it seems quite unlikely that any non-root filesystem is going to have a 
> smaller average Inode space usage than the root filesystem (I had expected 
> Maildir to be the pathological case of small files) it seems quite safe to 
> make the default be -i 49152 for non-root filesystems and be -i 32768 for 
> root 
> filesystems.
>
> Finally using ext4 features either through "mke2fs -t ext4" or "mke4fs" will 
> give you better fsck performance.  Are we doing ext4 by default nowadays?

The feature relevant here is that the filesystem knows how many inodes
have been used ever and only needs to scan those inodes. So if you only
ever used the first 1 inodes out of 1000 that is a huge time
saver.

> As an aside "mke2fs -t ext4" includes huge_file, dir_nlink, and extra_isize 
> while mke4fs doesn't.  This difference seems wrong to me.

Urgs. +1.

MfG
Goswin



--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739cevylx.fsf@frosties.localnet

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Russell Coker]

On Thu, 22 Dec 2011, Goswin von Brederlow  wrote:
> PS: I myself like a seperate /usr but I wouldn't use it for my parents.
> I do want a seperate /var and /home for them though so they can't DOS
> the system by filling up their home.

How would filling up /home DOS the system?

The only common program I can think of which fails hard when it runs out of 
disk space is Squid.  I expect that some DB servers also have serious problems 
but I don't think that they will be running a DB server on their home 
workstation.

My experience with systems I run for people who aren't computer experts (which 
includes my parents) is that filling /home causes various parts of their 
desktop environment to cease working (thus effectively DOSing the system) and 
they also just can't save files.

I have a separate partition for /home on such workstations, but this is just 
for ease of backups.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112220031.56019.russ...@coker.com.au

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Goswin von Brederlow]

Josselin Mouette  writes:

> Le samedi 17 décembre 2011 à 17:42 +0800, Thomas Goirand a écrit : 
>> I do recommend a separate /usr to anyone. It's *not* safe to say that,
>> and I know many people that agree with me. To me, it has, and still is,
>> the best choice. You have no rights to arbitrary decide what should
>> be/was/will be the recommended configuration. Your choice is not more
>> valid than mine, and (computer) science isn't about majorities anyway.
>
> True. But the fact that you are in minority doesn’t necessarily mean you
> are right, either.
>
>> Doing this has many advantage. Like, if your laptop has to unexpectedly
>> reboot (like when you inadvertently removed power cord when batteries
>> were not plugged, which happens often in real life), having separated
>> partitions usually makes the fsck faster.
>
> This is complete bullshit. With a journaled filesystem, the boot time
> will greatly increase with the number of filesystems to check. If no
> files were modified in /usr, they won’t be mentioned in the journal, and
> that’s all. But having one journal to parse for all the system is
> definitely a measurable improvement.

Also / and /usr can be read-only and definetly should be on a systems
likely to have power outages like laptops. And with a read-only
partition you have neither fsck nor journal replay. But even mounting an
extra filesystem does cost time. If you want to save the last
millisecond boot time you want / and /usr as one read-only filesystem.

MfG
Goswin





--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877h1qvyqv.fsf@frosties.localnet

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Goswin von Brederlow]

Steve Langasek  writes:

> On Fri, Dec 16, 2011 at 07:32:35PM +0100, Michael Biebl wrote:
>> On 16.12.2011 18:38, Joey Hess wrote:
>> > Christian PERRIER wrote:
>> >> I'm inclined to follow this advice and would indeed propose that the
>> >> "atomic" partman-auto recipe is kept, however without a separate /usr
>> >> partition (discussions on -devel and the current practice convinced me
>> >> that a separate /usr is seomthing that probably belongs to the former
>> >> century..:-)
>
>> > I don't think that d-i should be on the leading edge of this discussion.
>> > Once Debian has made up its mind, d-i can be updated to follow the
>> > consensus.
>
>> To me it looks like there is broad consensus that a separate /usr
>> partition should be considered deprecated and this option removed from
>> the installer.
>
> There isn't.  There's just a broad consensus among those who are talking
> about changing things.
>
> Some of us think this is completely bogus and are really sick of the same
> already-rebutted arguments being repeated over and over on the list as if
> that makes them true.

Then please once more for the record speak up and tell us why / and /usr
must be seperate partitions?

We are not talking about dropping support for having a seperate /usr
here. Just about D-I not creating / and /usr as seperate partition in
the "make more than one partition" automatic partitioning choice.

It is obvious that Debian still needs to support /usr being
seperate. But that isn't the issue. That is also why I don't agree with
Joey. D-I is the only one that makes the choice for the user and as such
is the one that can change the recepie.


MfG
Goswin

PS: I myself like a seperate /usr but I wouldn't use it for my parents.
I do want a seperate /var and /home for them though so they can't DOS
the system by filling up their home.



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bor2vz3o.fsf@frosties.localnet

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Russell Coker]

On Sun, 18 Dec 2011, Josselin Mouette  wrote:
> > Doing this has many advantage. Like, if your laptop has to unexpectedly
> > reboot (like when you inadvertently removed power cord when batteries
> > were not plugged, which happens often in real life), having separated
> > partitions usually makes the fsck faster.
> 
> This is complete bullshit. With a journaled filesystem, the boot time
> will greatly increase with the number of filesystems to check. If no
> files were modified in /usr, they won’t be mentioned in the journal, and
> that’s all. But having one journal to parse for all the system is
> definitely a measurable improvement.

If we want to improve fsck time then the best thing to do would be to consider 
a different default value for the -i option of mke2fs.

The current default is to have one Inode per 16K of disk space.  Of the 
Maildir format mail servers that I run the one with the smallest disk space 
used per Inode has 307G and 4773821 Inodes in use for an average of 67K per 
Inode.  A randomly selected Debian workstation with a lot of packages 
installed has for it's root filesystem 9.1G and 19 Inodes for an average 
of 49K.

As it seems quite unlikely that any non-root filesystem is going to have a 
smaller average Inode space usage than the root filesystem (I had expected 
Maildir to be the pathological case of small files) it seems quite safe to 
make the default be -i 49152 for non-root filesystems and be -i 32768 for root 
filesystems.

Finally using ext4 features either through "mke2fs -t ext4" or "mke4fs" will 
give you better fsck performance.  Are we doing ext4 by default nowadays?

As an aside "mke2fs -t ext4" includes huge_file, dir_nlink, and extra_isize 
while mke4fs doesn't.  This difference seems wrong to me.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/



--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112181327.08373.russ...@coker.com.au

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Josh Triplett]

On Sat, Dec 17, 2011 at 05:42:59PM +0800, Thomas Goirand wrote:
> On 12/17/2011 05:12 AM, Josh Triplett wrote:
> > And while we might
> > debate the usefulness of a separate /usr back and forth, I think I can
> > safely say that it won't become a *recommended* configuration anytime
> > soon. :)
> 
> I do recommend a separate /usr to anyone. It's *not* safe to say that,
> and I know many people that agree with me. To me, it has, and still is,
> the best choice. You have no rights to arbitrary decide what should
> be/was/will be the recommended configuration. Your choice is not more
> valid than mine, and (computer) science isn't about majorities anyway.

Let me clarify: I can safely say it won't become *Debian's* recommended
configuration anytime soon.  It has strong enough arguments against it
that while a vocal minority might manage to keep it around, I doubt
it will become the default.  The discussion would have to change quite
drastically for that to occur.

> On 12/17/2011 05:12 AM, Josh Triplett wrote:
> > For the installer, "easy" represents a significant component of
> > "do the job and do it well".
> > Sure; see below for a more detailed suggestion along these lines.
> > However, I also don't think that should stop us from optimizing
> > for the common case.
> 
> Well, commonly, for a desktop computer, I recommend separated /usr,
> /var, /tmp and /home. Reasonably, if you put enough space for it (for
> example, 16GB for usr, 8GB for var, 1GB for tmp) then you can set the
> rest for /home. Today's HDD are really big, and in most cases, this
> setup will work very well for a desktop, and you'll be able to install a
> really insane amount of software without filling up /usr or /var. If you
> then lack space, LVM is there.

Brand new laptops, *today*, come with as little as 300GB drives, or 80GB
SSDs.  Netbooks often have even less than that.  Wasting ~20GB of that
seems excessive.

And do you seriously expect the average user to go through the process
of an LVM resize?  "Possible" doesn't mean "easy".

> Doing this has many advantage. Like, if your laptop has to unexpectedly
> reboot (like when you inadvertently removed power cord when batteries
> were not plugged, which happens often in real life), having separated
> partitions usually makes the fsck faster. Only some of the partitions
> may have dirty bits to clean, and there's a very good chance your /usr
> (which holds a lot of files and is long to check) doesn't even need a
> check. That alone is a cool feature that justifies having a separate
> /usr for me.

Modern fsck runs very fast (in large part by not checking unused bits of
the filesystem).  Also, unless you've mounted some of those partitions
read-only, they'll all always need fsck when not cleanly shut down.

> When it comes to *real* newbies (here, I'm thinking about people like my
> father in law or my wife who really, don't want to know what is
> partitionning), they wont go to hit corner cases and fill any of the
> partitions of their HDD anyway. For them, I see no issue "wasting" a bit
> of space on multiple hundreds of GB space that will anyway never be used.

On the contrary, significant overlap exists between the set of users who
don't want to think about advanced concepts like partitioning and the
set of users quite capable of filling a disk and installing piles of
software.  If you really don't want to know about partitioning, you
don't want to deal with situations where you have plenty of free space
but not on the partitions where you need it.

> > Only in the case where you have such a big disk that you can afford to
> > waste a pile of space with mostly empty partitions. Personally [...]
> 
> In most general cases nowadays, we *do* have huge disks. Just have a
> look into what's available in the marketplace. If you lack space in one
> of the default partitions, you can resize using LVM anyway.

See above; we don't have sufficiently huge disks to waste enough space
that the non-/home partitions will never fill up, and we don't want to
inflict partition resizes on most users unnecessarily.

- Josh Triplett



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111217204726.GA22701@leaf

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Otavio Salvador]

On Sat, Dec 17, 2011 at 07:42, Thomas Goirand  wrote:

> On 12/17/2011 05:12 AM, Josh Triplett wrote:
> > And while we might
> > debate the usefulness of a separate /usr back and forth, I think I can
> > safely say that it won't become a *recommended* configuration anytime
> > soon. :)
>
> I do recommend a separate /usr to anyone. It's *not* safe to say that,
> and I know many people that agree with me. To me, it has, and still is,
> the best choice. You have no rights to arbitrary decide what should
> be/was/will be the recommended configuration. Your choice is not more
> valid than mine, and (computer) science isn't about majorities anyway.


Sure but Debian Installer defaults are. End point.


> ...
> In most general cases nowadays, we *do* have huge disks. Just have a
> look into what's available in the marketplace. If you lack space in one
> of the default partitions, you can resize using LVM anyway.
>

New users will think LVM is something to eat with bread or similar. This is
mostly as if I starting to try to convince to use Awesome WM as default
desktop install because I think it is more user-friendly (and it is, for my
type of use, but not for general use).

I do think you ought to stop to try to push your personal opinion too
hard... it is clear on this thread that most people do not agree with you
so lets go ahead and move topic.

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Josselin Mouette]

Le samedi 17 décembre 2011 à 17:42 +0800, Thomas Goirand a écrit : 
> I do recommend a separate /usr to anyone. It's *not* safe to say that,
> and I know many people that agree with me. To me, it has, and still is,
> the best choice. You have no rights to arbitrary decide what should
> be/was/will be the recommended configuration. Your choice is not more
> valid than mine, and (computer) science isn't about majorities anyway.

True. But the fact that you are in minority doesn’t necessarily mean you
are right, either.

> Doing this has many advantage. Like, if your laptop has to unexpectedly
> reboot (like when you inadvertently removed power cord when batteries
> were not plugged, which happens often in real life), having separated
> partitions usually makes the fsck faster.

This is complete bullshit. With a journaled filesystem, the boot time
will greatly increase with the number of filesystems to check. If no
files were modified in /usr, they won’t be mentioned in the journal, and
that’s all. But having one journal to parse for all the system is
definitely a measurable improvement.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


signature.asc
Description: This is a digitally signed message part

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Thomas Goirand]

On 12/17/2011 05:12 AM, Josh Triplett wrote:
> And while we might
> debate the usefulness of a separate /usr back and forth, I think I can
> safely say that it won't become a *recommended* configuration anytime
> soon. :)

I do recommend a separate /usr to anyone. It's *not* safe to say that,
and I know many people that agree with me. To me, it has, and still is,
the best choice. You have no rights to arbitrary decide what should
be/was/will be the recommended configuration. Your choice is not more
valid than mine, and (computer) science isn't about majorities anyway.

On 12/17/2011 05:12 AM, Josh Triplett wrote:
> For the installer, "easy" represents a significant component of
> "do the job and do it well".
> Sure; see below for a more detailed suggestion along these lines.
> However, I also don't think that should stop us from optimizing
> for the common case.

Well, commonly, for a desktop computer, I recommend separated /usr,
/var, /tmp and /home. Reasonably, if you put enough space for it (for
example, 16GB for usr, 8GB for var, 1GB for tmp) then you can set the
rest for /home. Today's HDD are really big, and in most cases, this
setup will work very well for a desktop, and you'll be able to install a
really insane amount of software without filling up /usr or /var. If you
then lack space, LVM is there.

Doing this has many advantage. Like, if your laptop has to unexpectedly
reboot (like when you inadvertently removed power cord when batteries
were not plugged, which happens often in real life), having separated
partitions usually makes the fsck faster. Only some of the partitions
may have dirty bits to clean, and there's a very good chance your /usr
(which holds a lot of files and is long to check) doesn't even need a
check. That alone is a cool feature that justifies having a separate
/usr for me.

When it comes to *real* newbies (here, I'm thinking about people like my
father in law or my wife who really, don't want to know what is
partitionning), they wont go to hit corner cases and fill any of the
partitions of their HDD anyway. For them, I see no issue "wasting" a bit
of space on multiple hundreds of GB space that will anyway never be used.

> Only in the case where you have such a big disk that you can afford to
> waste a pile of space with mostly empty partitions. Personally [...]

In most general cases nowadays, we *do* have huge disks. Just have a
look into what's available in the marketplace. If you lack space in one
of the default partitions, you can resize using LVM anyway.

Thomas



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eec6423.4040...@debian.org

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Josh Triplett]

On Sat, Dec 17, 2011 at 04:13:50AM +0800, Thomas Goirand wrote:
> Seems you're as much passionate about this topic as I am! :)
> At this point, I don't remotely hope to convince you, but perhaps you
> will find some of my points valid.

Likewise. :)

> On 12/17/2011 02:46 AM, Josh Triplett wrote:
> > Hence why I said "most people" (because I didn't want to imply
> > unanimity), but there's a difference between "consensus" and "complete
> > lack of dissent".  In any case, note that I specifically mentioned
> > separate /usr as a special-purpose configuration, not other separate
> > partitions.  I don't want to argue here that no possible reason exists
> > for separate /usr (that seems like another argument entirely, and a
> > mostly orthogonal one); I simply suggested that it represents an
> > uncommon configuration.  Do you really disagree with the statement
> > that separate /usr represents an uncommon configuration?
> > 
> >> On 12/16/2011 04:46 AM, Josh Triplett wrote:
> >>> Meanwhile, we don't want to steer any new users towards a setup with a
> >>> pile of different partitions, which makes their system more complex with
> >>> more potential failure modes.
> >>
> >> I hope that we are still the universal operating system,
> >> and that we don't want to force anyone to do anything.
> >> If I want to use many partitions, this is *my* call, and
> >> not everyone's business. Please don't try to force your
> >> view on partitioning to anyone.
> > 
> > Nobody stops you from using as many partitions as you like.  I've
> > suggested a change to the guided partitioner, which exists to make the
> > most common partition configurations easy, and to steer new Debian users
> > in the direction of configurations which will work well for them and not
> > give them too much trouble.
> 
> But I do not agree with your steering, just for the sake of making it
> more easy. We shouldn't only target "most common partition
> configurations easy", there's isn't a "one solution fits all", but
> really some choice depending on your needs. Showing to our users that
> separate /usr, /var, /tmp and /home can be a good choice is also
> important to me.

That sounds like you want the Debian installer to actively advocate for
your preferred partitioning scheme, even though it doesn't represent a
common configuration.

The guided partitioner exists in large part to say "If you don't have
custom needs, we recommend this configuration".  And while we might
debate the usefulness of a separate /usr back and forth, I think I can
safely say that it won't become a *recommended* configuration anytime
soon. :)

That represents the primary reason I filed this bug: to ensure that
people only end up with a separate /usr if they actively want one, not
because they saw the option in the installer and didn't know any better.

> Pushing users to do encryption would also be great. The Debian installer
> shouldn't only aim to be easy: it should do the job and do it well.

I don't think we can push encryption any more strongly than we do, short
of making it the default (and while I wish we could do that, I can see
a number of good reasons why we can't, not least of which systems that
need to boot unattended).

For the installer, "easy" represents a significant component of "do the
job and do it well".  I still remember doing installs via boot-floppies.
It certainly offered quite a lot more choices. :)

> I'd be happy if we had a partionner which could do as much as we can
> with right now with partman (which is: a lot!), just more efficiently.
> In other words: I'd like to do more complicated things faster.

Sure; see below for a more detailed suggestion along these lines.
However, I also don't think that should stop us from optimizing for the
common case.

> > A configuration with everything in one partition needs no extra
> > configuration; anyone who wants such a configuration will like what the
> > guided partitioner comes up with.
> 
> Of course, anyone who wants X will like X... What if I like Y?

This point went with the next one.  If you want X, you'll like the
option that gives you X.  If you prefer Y, it doesn't necessarily help
you to have an option for Z, any more than it helps you to have an
option for X.

> > A configuration with five separate
> > partitions seems almost impossible to provide sensible proportions for
> > that work for everyone without editing. And getting the proportions
> > wrong means people have to deal with strange and annoying cases like
> > /var filling up when /home has tons of room, or / filling up when /usr
> > has tons of room.
> 
> Sometimes, you just don't care about partition sizes, you just want them
> to be there automatically (as long as there's a separate /var and /tmp...).

Only in the case where you have such a big disk that you can afford to
waste a pile of space with mostly empty partitions.  Personally, when I
have a 1TB disk, I'd still like to have the ability to use 99% of that
for the contents of /

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Thomas Goirand]

Hi Josh,

Seems you're as much passionate about this topic as I am! :)
At this point, I don't remotely hope to convince you, but perhaps you
will find some of my points valid.

On 12/17/2011 02:46 AM, Josh Triplett wrote:
> Hence why I said "most people" (because I didn't want to imply
> unanimity), but there's a difference between "consensus" and "complete
> lack of dissent".  In any case, note that I specifically mentioned
> separate /usr as a special-purpose configuration, not other separate
> partitions.  I don't want to argue here that no possible reason exists
> for separate /usr (that seems like another argument entirely, and a
> mostly orthogonal one); I simply suggested that it represents an
> uncommon configuration.  Do you really disagree with the statement
> that separate /usr represents an uncommon configuration?
> 
>> On 12/16/2011 04:46 AM, Josh Triplett wrote:
>>> Meanwhile, we don't want to steer any new users towards a setup with a
>>> pile of different partitions, which makes their system more complex with
>>> more potential failure modes.
>>
>> I hope that we are still the universal operating system,
>> and that we don't want to force anyone to do anything.
>> If I want to use many partitions, this is *my* call, and
>> not everyone's business. Please don't try to force your
>> view on partitioning to anyone.
> 
> Nobody stops you from using as many partitions as you like.  I've
> suggested a change to the guided partitioner, which exists to make the
> most common partition configurations easy, and to steer new Debian users
> in the direction of configurations which will work well for them and not
> give them too much trouble.

But I do not agree with your steering, just for the sake of making it
more easy. We shouldn't only target "most common partition
configurations easy", there's isn't a "one solution fits all", but
really some choice depending on your needs. Showing to our users that
separate /usr, /var, /tmp and /home can be a good choice is also
important to me.

Pushing users to do encryption would also be great. The Debian installer
shouldn't only aim to be easy: it should do the job and do it well.

I'd be happy if we had a partionner which could do as much as we can
with right now with partman (which is: a lot!), just more efficiently.
In other words: I'd like to do more complicated things faster.

> A configuration with everything in one partition needs no extra
> configuration; anyone who wants such a configuration will like what the
> guided partitioner comes up with.

Of course, anyone who wants X will like X... What if I like Y?

> A configuration with five separate
> partitions seems almost impossible to provide sensible proportions for
> that work for everyone without editing. And getting the proportions
> wrong means people have to deal with strange and annoying cases like
> /var filling up when /home has tons of room, or / filling up when /usr
> has tons of room.

Sometimes, you just don't care about partition sizes, you just want them
to be there automatically (as long as there's a separate /var and /tmp...).

But well anyway, that's a valid reason for giving *more* template
choices and control in partman not less! :) Indeed, I'd be cool to
select such layout, then just quickly just enter sizes on the LVM,
without having to define types and mount points manually (which takes
soo muuch time).

I have tried multiple times to convince Otavio at the last Debconf11
that I believed partman should also be providing templates with RAID1 /
RAID10 setups, since a lot of people are using it in the server room. I
had a hard time, and I think he stand in your side for less choices,
since his answer was that I should make a custom ISO for myself (which
doesn't satisfy me, really).

>>> Please consider removing the option in the guided partitioner for
>>> separate /usr, /var, and /tmp partitions; that would leave only the "All
>>> files in one partition" and "Separate /home partition" setups, both of
>>> which potentially make sense for users of the guided partitioner.
>>
>> Please don't remove the above option, I like it, and I
>> don't see why it needs to be removed just because
>> you Josh (and maybe others) don't like/use it.
> 
> That line of reasoning would never let Debian remove *anything*, ever.

We have debconf priority and the expert install mode for a reason. If
you said you want to remove some templates from the non-expert
installer, then I'd say it's a good idea. But not for the expert mode.

>> You feel like a separate partition for /home is useful.
> 
> Actually, I don't, but I didn't advocate that today. :)
> 
>> Good for you, and your desktop. But when it comes
>> to servers, the /home separate partition is useless,
>> and having a separate /var makes things faster.
> 
> Exactly my point, then.  The guided partitioning option I mentioned
> makes /home, /usr, /var, and /tmp all separate partitions.  You just
> said you don't want a separate /home, and you d

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Bob Proulx]

Steve Langasek wrote:
> Michael Biebl wrote:
> > To me it looks like there is broad consensus that a separate /usr
> > partition should be considered deprecated and this option removed from
> > the installer.
> 
> There isn't.  There's just a broad consensus among those who are talking
> about changing things.

Unfortunately the ones that are the most agressive by shouting loudest
and repeating the most often are sometimes the most successful.

> Some of us think this is completely bogus and are really sick of the same
> already-rebutted arguments being repeated over and over on the list as if
> that makes them true.

Is there a way to collect objective information such that we would be
able to know something with data other than with emotions?

If the data showed that some wanted it one way and others wanted it
the opposite way (which is of course what it would show) then how
would having this data help or hinder either side?

I will be one of the disenfranchised if /usr is deprecated.

Bob


signature.asc
Description: Digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Marco d'Itri]

On Dec 16, Josh Triplett  wrote:

> A configuration with everything in one partition needs no extra
> configuration; anyone who wants such a configuration will like what the
> guided partitioner comes up with.  A configuration with five separate
> partitions seems almost impossible to provide sensible proportions for
> that work for everyone without editing.  And getting the proportions
> wrong means people have to deal with strange and annoying cases like
> /var filling up when /home has tons of room, or / filling up when /usr
> has tons of room.
+1

> That line of reasoning would never let Debian remove *anything*, ever.
And is one of the causes of the stagnation and lack of innovation in
Debian.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Joey Hess]

Josh Triplett wrote:
> Exactly my point, then.  The guided partitioning option I mentioned
> makes /home, /usr, /var, and /tmp all separate partitions.  You just
> said you don't want a separate /home, and you do want a separate /var.
> Thus, you have custom requirements that don't fit the guided option, and
> you'd need to use the manual partitioner instead.  I argue that the same
> holds true for almost anyone who might want something similar to that
> guided option: they don't actually want what the guided option provides.

That's not how d-i's partitioner works. You can select a recipe and
then modify the partition scheme it generates to meet your exact needs.

> Keep in mind that the installer used to ask several times as many
> questions as it does now.  Debian has managed to improve it drastically,
> and in doing so removed some choices that I'd bet a non-zero number of
> people in the universe cared about.  As a net result, the installer now
> proves simpler and easier to deal with for everyone.

And one of those question removal processes involved coming up with the
current list where the user choses from some common recipes, or chooses
to fully manually partition. Since we *have* to ask a question that
provides that last option, providing the other options is free from a
number of questions POV.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Joey Hess]

Steve Langasek wrote:
> There isn't.  There's just a broad consensus among those who are talking
> about changing things.

Yes.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Russ Allbery]

Michael Biebl  writes:
> On 16.12.2011 18:38, Joey Hess wrote:
>> Christian PERRIER wrote:

>>> I'm inclined to follow this advice and would indeed propose that the
>>> "atomic" partman-auto recipe is kept, however without a separate /usr
>>> partition (discussions on -devel and the current practice convinced me
>>> that a separate /usr is seomthing that probably belongs to the former
>>> century..:-)

>> I don't think that d-i should be on the leading edge of this
>> discussion.  Once Debian has made up its mind, d-i can be updated to
>> follow the consensus.

> To me it looks like there is broad consensus that a separate /usr
> partition should be considered deprecated and this option removed from
> the installer.

There's a bit of disagreement over the deprecation part still, but I think
there's a pretty good consensus that people with a separate /usr from /
are doing so for fairly edge-case situations, such as wanting a partially
encrypted file system, and hence are not the target audience for the
pre-constructed partitioning choices in d-i.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa6s5osa@windlord.stanford.edu

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Josh Triplett]

On Fri, Dec 16, 2011 at 09:11:22PM +0800, Thomas Goirand wrote:
> On 12/16/2011 04:46 AM, Josh Triplett wrote:
> > In all of the recent discussions about separate /usr partitions, most
> > people seem to acknowledge them as unusual, special-purpose
> > configurations, even those who use them.
> 
> I do *not* agree that there's such a consensus.

Hence why I said "most people" (because I didn't want to imply
unanimity), but there's a difference between "consensus" and "complete
lack of dissent".  In any case, note that I specifically mentioned
separate /usr as a special-purpose configuration, not other separate
partitions.  I don't want to argue here that no possible reason exists
for separate /usr (that seems like another argument entirely, and a
mostly orthogonal one); I simply suggested that it represents an
uncommon configuration.  Do you really disagree with the statement
that separate /usr represents an uncommon configuration?

> On 12/16/2011 04:46 AM, Josh Triplett wrote:
> > Meanwhile, we don't want to steer any new users towards a setup with a
> > pile of different partitions, which makes their system more complex with
> > more potential failure modes.
> 
> I hope that we are still the universal operating system,
> and that we don't want to force anyone to do anything.
> If I want to use many partitions, this is *my* call, and
> not everyone's business. Please don't try to force your
> view on partitioning to anyone.

Nobody stops you from using as many partitions as you like.  I've
suggested a change to the guided partitioner, which exists to make the
most common partition configurations easy, and to steer new Debian users
in the direction of configurations which will work well for them and not
give them too much trouble.

A configuration with everything in one partition needs no extra
configuration; anyone who wants such a configuration will like what the
guided partitioner comes up with.  A configuration with five separate
partitions seems almost impossible to provide sensible proportions for
that work for everyone without editing.  And getting the proportions
wrong means people have to deal with strange and annoying cases like
/var filling up when /home has tons of room, or / filling up when /usr
has tons of room.

> > In the most recent thread, I noticed that someone mentioned they
> > primarily chose a setup with a separate /usr partition because the
> > installer offered such a setup as one of the standard guided
> > partitioning options.
> >
> > Please consider removing the option in the guided partitioner for
> > separate /usr, /var, and /tmp partitions; that would leave only the "All
> > files in one partition" and "Separate /home partition" setups, both of
> > which potentially make sense for users of the guided partitioner.
> 
> Please don't remove the above option, I like it, and I
> don't see why it needs to be removed just because
> you Josh (and maybe others) don't like/use it.

That line of reasoning would never let Debian remove *anything*, ever.
Sometimes it makes sense to optimize for the common and recommended
case, as long as the uncommon case remains *possible*, which it does
here.  (And sometimes it even makes sense to optimize for the common and
recommended case by making the uncommon case impossible, but note that I
didn't suggest that in this case.)

> You feel like a separate partition for /home is useful.

Actually, I don't, but I didn't advocate that today. :)

> Good for you, and your desktop. But when it comes
> to servers, the /home separate partition is useless,
> and having a separate /var makes things faster.

Exactly my point, then.  The guided partitioning option I mentioned
makes /home, /usr, /var, and /tmp all separate partitions.  You just
said you don't want a separate /home, and you do want a separate /var.
Thus, you have custom requirements that don't fit the guided option, and
you'd need to use the manual partitioner instead.  I argue that the same
holds true for almost anyone who might want something similar to that
guided option: they don't actually want what the guided option provides.

> Also, having a separate /tmp avoids that the rootfs
> gets full, and I consider it quite important especially
> on servers. I would recommend using it for absolutely
> *every* setup (desktop or servers) as a security measure,
> especially considering any application can fill up the
> temp space.

Note that newly installed Debian systems have /tmp on tmpfs by default.

Also, it really doesn't matter for single-user systems, only for
multi-user systems with untrusted users.

> > Anyone desiring a setup with more separate partitions should have no
> > trouble using the manual partitioner to create whatever custom
> > configuration they desire.
> 
> And we have even less trouble using the automated option,
> also it's a way faster than doing it manually. Please don't
> remove it.
> 
> Again, the way *I* and *others* use my/their computers
> is their choice. Please do no

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Christian PERRIER]

Quoting Michael Biebl (bi...@debian.org):

> > I don't think that d-i should be on the leading edge of this discussion.
> > Once Debian has made up its mind, d-i can be updated to follow the
> > consensus.
> 
> To me it looks like there is broad consensus that a separate /usr
> partition should be considered deprecated and this option removed from
> the installer.

That was my feeling too (consensus about dropping a strong support for
a separate /usr by keeping it in the atomic recipe). Which is why I
think we can do it now. As of now, I have seen Thomas Goirand strongly
advocating *for* the *possibility* of a separate /usrwhich will
still be possible (just less convenient if we drop it from the atomic
recipe). 

After all, by dropping the separate /usr in the atomic recipe, we
don't make it impossible, we make it less easy to do.



signature.asc
Description: Digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Steve Langasek]

On Fri, Dec 16, 2011 at 07:32:35PM +0100, Michael Biebl wrote:
> On 16.12.2011 18:38, Joey Hess wrote:
> > Christian PERRIER wrote:
> >> I'm inclined to follow this advice and would indeed propose that the
> >> "atomic" partman-auto recipe is kept, however without a separate /usr
> >> partition (discussions on -devel and the current practice convinced me
> >> that a separate /usr is seomthing that probably belongs to the former
> >> century..:-)

> > I don't think that d-i should be on the leading edge of this discussion.
> > Once Debian has made up its mind, d-i can be updated to follow the
> > consensus.

> To me it looks like there is broad consensus that a separate /usr
> partition should be considered deprecated and this option removed from
> the installer.

There isn't.  There's just a broad consensus among those who are talking
about changing things.

Some of us think this is completely bogus and are really sick of the same
already-rebutted arguments being repeated over and over on the list as if
that makes them true.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Michael Biebl]

On 16.12.2011 18:38, Joey Hess wrote:
> Christian PERRIER wrote:
>> I'm inclined to follow this advice and would indeed propose that the
>> "atomic" partman-auto recipe is kept, however without a separate /usr
>> partition (discussions on -devel and the current practice convinced me
>> that a separate /usr is seomthing that probably belongs to the former
>> century..:-)
> 
> I don't think that d-i should be on the leading edge of this discussion.
> Once Debian has made up its mind, d-i can be updated to follow the
> consensus.

To me it looks like there is broad consensus that a separate /usr
partition should be considered deprecated and this option removed from
the installer.

If that means dropping the multi-partition option altogether or just
removing /usr from the "atomic" partman-auto recipe is something I'd
leave up to the d-i team to decide. Personally I'd be fine with either
solution.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Joey Hess]

Christian PERRIER wrote:
> I'm inclined to follow this advice and would indeed propose that the
> "atomic" partman-auto recipe is kept, however without a separate /usr
> partition (discussions on -devel and the current practice convinced me
> that a separate /usr is seomthing that probably belongs to the former
> century..:-)

I don't think that d-i should be on the leading edge of this discussion.
Once Debian has made up its mind, d-i can be updated to follow the
consensus.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Thomas Goirand]

On 12/16/2011 04:46 AM, Josh Triplett wrote:
> In all of the recent discussions about separate /usr partitions, most
> people seem to acknowledge them as unusual, special-purpose
> configurations, even those who use them.

I do *not* agree that there's such a consensus.

On 12/16/2011 04:46 AM, Josh Triplett wrote:
> Meanwhile, we don't want to steer any new users towards a setup with a
> pile of different partitions, which makes their system more complex with
> more potential failure modes.
>   

I hope that we are still the universal operating system,
and that we don't want to force anyone to do anything.
If I want to use many partitions, this is *my* call, and
not everyone's business. Please don't try to force your
view on partitioning to anyone.

> In the most recent thread, I noticed that someone mentioned they
> primarily chose a setup with a separate /usr partition because the
> installer offered such a setup as one of the standard guided
> partitioning options.
>
> Please consider removing the option in the guided partitioner for
> separate /usr, /var, and /tmp partitions; that would leave only the "All
> files in one partition" and "Separate /home partition" setups, both of
> which potentially make sense for users of the guided partitioner.
>   

Please don't remove the above option, I like it, and I
don't see why it needs to be removed just because
you Josh (and maybe others) don't like/use it.

You feel like a separate partition for /home is useful.
Good for you, and your desktop. But when it comes
to servers, the /home separate partition is useless,
and having a separate /var makes things faster.

Also, having a separate /tmp avoids that the rootfs
gets full, and I consider it quite important especially
on servers. I would recommend using it for absolutely
*every* setup (desktop or servers) as a security measure,
especially considering any application can fill up the
temp space.

> Anyone desiring a setup with more separate partitions should have no
> trouble using the manual partitioner to create whatever custom
> configuration they desire.
>   

And we have even less trouble using the automated option,
also it's a way faster than doing it manually. Please don't
remove it.

Again, the way *I* and *others* use my/their computers
is their choice. Please do not remove this choice from
me/them.

Thomas Goirand (zigo)




-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eeb437a.8070...@debian.org

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Roger Leigh]

On Fri, Dec 16, 2011 at 07:34:16AM +0100, Christian PERRIER wrote:
> (reducing CC as I guess that most are subscribed to -devel)
> 
> Quoting Russ Allbery (r...@debian.org):
> 
> > I don't think these things are alike.  Separating /var and /tmp from the
> > rest of the file systems is done because those partitions contain varying
> > amounts of data and often fill if something goes wrong, but can fill
> > without impacting the rest of the system and allowing easy recovery if
> > they're not on the same partition as everything else.
> > 
> > Separating /var continues to be good and recommended practice if you're
> > running anything that's likely to produce a lot of output, IMO.  (/tmp
> > should probalby just be tmpfs, but that's another discussion.)
> 
> I'm inclined to follow this advice and would indeed propose that the
> "atomic" partman-auto recipe is kept, however without a separate /usr
> partition (discussions on -devel and the current practice convinced me
> that a separate /usr is seomthing that probably belongs to the former
> century..:-)
> 
> So, would it be OK for participants in this discussion is we, in the
> installer, just drop separate /usr but keep the atomic recipe (which
> is not the default choice, by the way)?

Dropping /usr is a good idea, I think, and continuing to keep /var
separate would also be sensible.

Regarding /tmp, we're now defaulting to a tmpfs for new installs, so
I'm not certain if having a separate /tmp by default is a good idea
or not.  I would certainly like for /tmp in particular (and tmpfses
in general) to become configurable through the partitioner, which
would then also check that sufficient swap is also allocated at the
same time.

Once we have /etc/fstab.d fully supported by mount (with the next
util-linux release, probably in early January), I will be looking
at making all the initscripts mountpoints currently hardcoded in
the init scripts like mountkernfs etc. into conffiles in fstab.d.
It would then be possible for the installer to edit these files
quite simply to change the defaults, perhaps using the partitioner
as a frontend.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111216103012.gm17...@codelibre.net

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Christian PERRIER]

(reducing CC as I guess that most are subscribed to -devel)

Quoting Russ Allbery (r...@debian.org):

> I don't think these things are alike.  Separating /var and /tmp from the
> rest of the file systems is done because those partitions contain varying
> amounts of data and often fill if something goes wrong, but can fill
> without impacting the rest of the system and allowing easy recovery if
> they're not on the same partition as everything else.
> 
> Separating /var continues to be good and recommended practice if you're
> running anything that's likely to produce a lot of output, IMO.  (/tmp
> should probalby just be tmpfs, but that's another discussion.)

I'm inclined to follow this advice and would indeed propose that the
"atomic" partman-auto recipe is kept, however without a separate /usr
partition (discussions on -devel and the current practice convinced me
that a separate /usr is seomthing that probably belongs to the former
century..:-)


So, would it be OK for participants in this discussion is we, in the
installer, just drop separate /usr but keep the atomic recipe (which
is not the default choice, by the way)?




signature.asc
Description: Digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Russ Allbery]

Josh Triplett  writes:

> In all of the recent discussions about separate /usr partitions, most
> people seem to acknowledge them as unusual, special-purpose
> configurations, even those who use them.  To the extent they have a use
> at all, they primarily have a use for people who have very specific
> reasons for wanting them, and all of those people will know how to
> handle partitioning.  To a lesser extent, that holds true for having
> separate partitions for /var, /tmp, or other top-level directories.  It
> seems likely that any such setup will have custom requirements.

I don't think these things are alike.  Separating /var and /tmp from the
rest of the file systems is done because those partitions contain varying
amounts of data and often fill if something goes wrong, but can fill
without impacting the rest of the system and allowing easy recovery if
they're not on the same partition as everything else.

Separating /var continues to be good and recommended practice if you're
running anything that's likely to produce a lot of output, IMO.  (/tmp
should probalby just be tmpfs, but that's another discussion.)

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3bph1ww@windlord.stanford.edu

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Marco d'Itri]

On Dec 15, Josh Triplett  wrote:

> Anyone desiring a setup with more separate partitions should have no
> trouble using the manual partitioner to create whatever custom
> configuration they desire.
I agree.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Josh Triplett]

Package: partman-auto
Severity: normal

In all of the recent discussions about separate /usr partitions, most
people seem to acknowledge them as unusual, special-purpose
configurations, even those who use them.  To the extent they have a use
at all, they primarily have a use for people who have very specific
reasons for wanting them, and all of those people will know how to
handle partitioning.  To a lesser extent, that holds true for having
separate partitions for /var, /tmp, or other top-level directories.  It
seems likely that any such setup will have custom requirements.

Meanwhile, we don't want to steer any new users towards a setup with a
pile of different partitions, which makes their system more complex with
more potential failure modes.

In the most recent thread, I noticed that someone mentioned they
primarily chose a setup with a separate /usr partition because the
installer offered such a setup as one of the standard guided
partitioning options.

Please consider removing the option in the guided partitioner for
separate /usr, /var, and /tmp partitions; that would leave only the "All
files in one partition" and "Separate /home partition" setups, both of
which potentially make sense for users of the guided partitioner.
Anyone desiring a setup with more separate partitions should have no
trouble using the manual partitioner to create whatever custom
configuration they desire.

- Josh Triplett



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111215204633.4096.81498.reportbug@leaf