Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #195849 > unrolled thread

making more room in root partition for distribution upgrade

Back to article view | Back to linux.debian.user

Contents

  making more room in root partition for distribution upgrade Mark Copper <mcopper@straitcity.com> - 2018-05-18 01:10 +0200
    Re: making more room in root partition for distribution upgrade bw <bwtnguy@yahoo.com> - 2018-05-18 01:40 +0200
      Re: making more room in root partition for distribution upgrade Mark Copper <mcopper@straitcity.com> - 2018-05-18 02:10 +0200
        Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-20 10:30 +0200
          Re: making more room in root partition for distribution upgrade Mark Copper <mcopper@straitcity.com> - 2018-05-21 18:20 +0200
            Re: making more room in root partition for distribution upgrade Curt <curty@free.fr> - 2018-05-21 18:50 +0200
              Re: making more room in root partition for distribution upgrade Mark Copper <mcopper@straitcity.com> - 2018-05-21 19:00 +0200
                Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-21 19:30 +0200
            Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-21 19:30 +0200
              Re: making more room in root partition for distribution upgrade Mark Copper <mcopper@straitcity.com> - 2018-05-25 02:30 +0200
                Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-25 20:30 +0200
    Re: making more room in root partition for distribution upgrade Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-18 03:10 +0200
    Re: making more room in root partition for distribution upgrade Andy Smith <andy@strugglers.net> - 2018-05-18 03:30 +0200
      Re: making more room in root partition for distribution upgrade Rick Thomas <rbthomas@pobox.com> - 2018-05-18 13:10 +0200
        Re: making more room in root partition for distribution upgrade Andy Smith <andy@strugglers.net> - 2018-05-18 14:10 +0200
    Re: making more room in root partition for distribution upgrade Felix Miata <mrmazda@earthlink.net> - 2018-05-18 05:00 +0200
    Re: making more room in root partition for distribution upgrade ntrfug <ntrfug@cox.net> - 2018-05-19 16:30 +0200
      Re: making more room in root partition for distribution upgrade Charlie S <taoquester@gmail.com> - 2018-05-20 08:00 +0200
        Re: making more room in root partition for distribution upgrade songbird <songbird@anthive.com> - 2018-05-20 14:40 +0200
          Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-20 15:10 +0200
            Re: making more room in root partition for distribution upgrade Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-20 16:30 +0200
              Re: making more room in root partition for distribution upgrade Stefan Monnier <monnier@iro.umontreal.ca> - 2018-05-20 16:40 +0200
                Re: making more room in root partition for distribution upgrade Reco <recoverym4n@gmail.com> - 2018-05-20 17:30 +0200
                  Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-20 20:50 +0200
                    Re: making more room in root partition for distribution upgrade Reco <recoverym4n@gmail.com> - 2018-05-20 21:40 +0200
                      Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-20 22:00 +0200
              Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-20 20:50 +0200
              Re: making more room in root partition for distribution upgrade Richard Hector <richard@walnut.gen.nz> - 2018-05-21 07:20 +0200
            Re: making more room in root partition for distribution upgrade songbird <songbird@anthive.com> - 2018-05-21 02:10 +0200
              Re: making more room in root partition for distribution upgrade Andy Smith <andy@strugglers.net> - 2018-05-21 08:00 +0200
                Re: making more room in root partition for distribution upgrade Curt <curty@free.fr> - 2018-05-21 10:30 +0200
                  Re: making more room in root partition for distribution upgrade Joe <joe@jretrading.com> - 2018-05-21 11:00 +0200
                    Re: making more room in root partition for distribution upgrade Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-21 17:00 +0200
                      Re: making more room in root partition for distribution upgrade Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-21 21:10 +0200
                        Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-21 21:50 +0200
                          Re: making more room in root partition for distribution upgrade Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-21 22:20 +0200
                            Re: making more room in root partition for distribution upgrade Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-21 23:00 +0200
                            Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-21 23:20 +0200
                              Re: making more room in root partition for distribution upgrade Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-22 00:20 +0200
                                Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-22 20:30 +0200
                                  Re: making more room in root partition for distribution upgrade Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-22 21:00 +0200
                                    Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-22 22:30 +0200
                                      Re: making more room in root partition for distribution upgrade deloptes <deloptes@gmail.com> - 2018-05-22 23:30 +0200
                                  Re: making more room in root partition for distribution upgrade Richard Hector <richard@walnut.gen.nz> - 2018-05-22 22:00 +0200
                                  Re: making more room in root partition for distribution upgrade Jerome Kutche <n9lya@uronode.n9lya.ampr.org> - 2018-05-22 23:40 +0200
                                    Re: making more room in root partition for distribution upgrade Stefan Monnier <monnier@iro.umontreal.ca> - 2018-05-23 03:20 +0200
                                    Re: making more room in root partition for distribution upgrade Curt <curty@free.fr> - 2018-05-23 10:30 +0200
                  Re: making more room in root partition for distribution upgrade Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-21 14:20 +0200
                    Re: making more room in root partition for distribution upgrade David Baron <dbaron770@gmail.com> - 2018-05-21 15:10 +0200
                Re: making more room in root partition for distribution upgrade David Wright <deblis@lionunicorn.co.uk> - 2018-05-21 16:00 +0200
                  Re: making more room in root partition for distribution upgrade Miroslav Skoric <skoric@eunet.rs> - 2018-05-25 11:40 +0200
                    Re: making more room in root partition for distribution upgrade David Wright <deblis@lionunicorn.co.uk> - 2018-05-25 22:50 +0200
                      Re: making more room in root partition for distribution upgrade Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-25 23:20 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#195932

On Sun, 20 May 2018 15:03:37 +0200 Pascal Hambourg said:
> Le 20/05/2018 à 14:33, songbird a écrit :
>> 
>>    in my last system i had many different partitions like that but
>> with the new system i decided that was wasting too much space and  
> 
> Then LVM is your friend. You can create as many logical volumes as you 
> like with minimal sizes and easily extend them when needed. This way you 
> don't waste space in overprovisioning.

LVM greatly simplifies the partitioning part of the chore. But you still need
to do the content management part[*] before shrinking / after enlarging an LV,
don't you?

[*] backup, umount/swapoff, resize2fs/mkswap, mount/swapon, (unlikely but
possibly: restore)

Regards
-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [next] | [standalone]

#195933

> [*] backup, umount/swapoff, resize2fs/mkswap, mount/swapon, (unlikely but
> possibly: restore)

    lvextend --resizefs ...

will work without you needing to unmount the file-system.


        Stefan

[toc] | [prev] | [next] | [standalone]

#195934

	Hi.

On Sun, May 20, 2018 at 10:30:26AM -0400, Stefan Monnier wrote:
> > [*] backup, umount/swapoff, resize2fs/mkswap, mount/swapon, (unlikely but
> > possibly: restore)
> 
>     lvextend --resizefs ...
> 
> will work without you needing to unmount the file-system.

You forgot to add 'unless you try to shrink the filesystem, or still use
reiserfs'.

Reco

[toc] | [prev] | [next] | [standalone]

#195936

Le 20/05/2018 à 17:23, Reco a écrit :
> 
> On Sun, May 20, 2018 at 10:30:26AM -0400, Stefan Monnier wrote:
>>
>>      lvextend --resizefs ...
>>
>> will work without you needing to unmount the file-system.
> 
> You forgot to add 'unless you try to shrink the filesystem, or still use
> reiserfs'.

Or use btrfs which supports online shrinking.

[toc] | [prev] | [next] | [standalone]

#195939

On Sun, May 20, 2018 at 08:48:05PM +0200, Pascal Hambourg wrote:
> Le 20/05/2018 à 17:23, Reco a écrit :
> > 
> > On Sun, May 20, 2018 at 10:30:26AM -0400, Stefan Monnier wrote:
> > > 
> > >      lvextend --resizefs ...
> > > 
> > > will work without you needing to unmount the file-system.
> > 
> > You forgot to add 'unless you try to shrink the filesystem, or still use
> > reiserfs'.
> 
> Or use btrfs which supports online shrinking.

Two questions:

1) lvextend uses fsadm, fsadm does not know anything about brtfs.
How it's supposed to work?

2) Why does anyone would want to create btrfs inside the Logical Volume?

Reco

[toc] | [prev] | [next] | [standalone]

#195943

Le 20/05/2018 à 21:34, Reco a écrit :
> On Sun, May 20, 2018 at 08:48:05PM +0200, Pascal Hambourg wrote:
>> Le 20/05/2018 à 17:23, Reco a écrit :
>>>
>>> On Sun, May 20, 2018 at 10:30:26AM -0400, Stefan Monnier wrote:
>>>>
>>>>       lvextend --resizefs ...
>>>>
>>>> will work without you needing to unmount the file-system.
>>>
>>> You forgot to add 'unless you try to shrink the filesystem, or still use
>>> reiserfs'.
>>
>> Or use btrfs which supports online shrinking.
> 
> Two questions:
> 
> 1) lvextend uses fsadm, fsadm does not know anything about brtfs.
> How it's supposed to work?

Well then, until it does, use "btrfs filesystem resize" instead.
The important thing is that you do not have to unmount the filesystem.

> 2) Why does anyone would want to create btrfs inside the Logical Volume?

For the same reasons as any other type of contents.
Why not ? Some features of LVM and btrfs may appear redundant, but they 
do not operate at the same layer.

[toc] | [prev] | [next] | [standalone]

#195935

Le 20/05/2018 à 16:19, Abdullah Ramazanoğlu a écrit :
> On Sun, 20 May 2018 15:03:37 +0200 Pascal Hambourg said:
>> Le 20/05/2018 à 14:33, songbird a écrit :
>>>
>>> in my last system i had many different partitions like that but
>>> with the new system i decided that was wasting too much space and
>>
>> Then LVM is your friend. You can create as many logical volumes as you
>> like with minimal sizes and easily extend them when needed. This way you
>> don't waste space in overprovisioning.
> 
> LVM greatly simplifies the partitioning part of the chore. But you still need
> to do the content management part[*] before shrinking / after enlarging an LV,
> don't you?
> 
> [*] backup, umount/swapoff, resize2fs/mkswap, mount/swapon, (unlikely but
> possibly: restore)

Most common filesystems such as ext2/3/4, xfs or btrfs can be extended 
online while mounted. Extend the logical volume, then resize the 
filesystem, that's it. A swap cannot be extended while in use [*], but 
you can create and add a new swap instead. If you install with minimal 
logical volume sizes and leave plenty of free space in the volume group 
for future logical volume growth, you do not need to reduce existing 
logical volumes to gain free space.

[*] Actually it cannot be resized even when not in use, but it can be 
recreated with the same UUID and/or label, which provides about the same 
result as offline resizing would.

[toc] | [prev] | [next] | [standalone]

#195950

[Multipart message — attachments visible in raw view] — view raw

On 21/05/18 02:19, Abdullah Ramazanoğlu wrote:
> LVM greatly simplifies the partitioning part of the chore. But you still need
> to do the content management part[*] before shrinking / after enlarging an LV,
> don't you?
> 
> [*] backup, umount/swapoff, resize2fs/mkswap, mount/swapon, (unlikely but
> possibly: restore)

How much risk is there really these days in resizing a filesystem? I
don't think I've ever had a problem (that required restoring from
backup) in ~15 years. I usually use xfs for anything beyond the root fs.

The most significant problem I think I had was trying to take LVM
snapshots of an xfs filesystem - I don't know for sure if it was that
combination that was the problem, or if it was, whether it still is.

Richard

[toc] | [prev] | [next] | [standalone]

#195948

Pascal Hambourg wrote:
> Le 20/05/2018 à 14:33, songbird a écrit :
>> 
>>    in my last system i had many different partitions like that but
>> with the new system i decided that was wasting too much space and
>
> Then LVM is your friend. You can create as many logical volumes as you 
> like with minimal sizes and easily extend them when needed. This way you 
> don't waste space in overprovisioning.

  added complexity for a simple system such as mine
is rather pointless.

  i don't need to learn yet another layer for dealing 
with space issues.  i've already got it going, everything 
works as desired.

  if for some reason i do need such complexity i do
know where to find it.


  songbird

[toc] | [prev] | [next] | [standalone]

#195951

Hello,

On Sun, May 20, 2018 at 07:59:48PM -0400, songbird wrote:
> Pascal Hambourg wrote:
> > Then LVM is your friend. You can create as many logical volumes as you 
> > like with minimal sizes and easily extend them when needed. This way you 
> > don't waste space in overprovisioning.
> 
>   added complexity for a simple system such as mine
> is rather pointless.

I hear that a lot from people who later find themselves doing
cosmetic surgery on their partition table because they weren't able
to initially size things properly.

It's quite a manageable bit of learning that pays dividends for the
whole rest of your time.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Please consider the environment before reading this e-mail.
 — John Levine

[toc] | [prev] | [next] | [standalone]

#195953

On 2018-05-21, Andy Smith <andy@strugglers.net> wrote:
> Hello,
>
> On Sun, May 20, 2018 at 07:59:48PM -0400, songbird wrote:
>> Pascal Hambourg wrote:
>> > Then LVM is your friend. You can create as many logical volumes as you 
>> > like with minimal sizes and easily extend them when needed. This way you 
>> > don't waste space in overprovisioning.
>> 
>>   added complexity for a simple system such as mine
>> is rather pointless.
>
> I hear that a lot from people who later find themselves doing
> cosmetic surgery on their partition table because they weren't able
> to initially size things properly.

Verily in the installer I chose automatic partitioning because of my
partitioning phobia many moons ago and was allotted a 9G '/' and a 1.4T
'home' (as well as swap the size of my ego), so find myself in a
predicament similar to that of the OP.

(A recent thread seemed to imply that the installer's automagical
partitioner for LVM leaves little or no empty room for growth, thus
vitiating somewhat the very raison d'être of LVM at its root.)

> It's quite a manageable bit of learning that pays dividends for the
> whole rest of your time.
>
> Cheers,
> Andy
>


-- 

[toc] | [prev] | [next] | [standalone]

#195955

On Mon, 21 May 2018 08:26:01 +0000 (UTC)
Curt <curty@free.fr> wrote:

> On 2018-05-21, Andy Smith <andy@strugglers.net> wrote:
> > Hello,
> >
> > On Sun, May 20, 2018 at 07:59:48PM -0400, songbird wrote:  
> >> Pascal Hambourg wrote:  
> >> > Then LVM is your friend. You can create as many logical volumes
> >> > as you like with minimal sizes and easily extend them when
> >> > needed. This way you don't waste space in overprovisioning.  
> >> 
> >>   added complexity for a simple system such as mine
> >> is rather pointless.  
> >
> > I hear that a lot from people who later find themselves doing
> > cosmetic surgery on their partition table because they weren't able
> > to initially size things properly.  
> 
> Verily in the installer I chose automatic partitioning because of my
> partitioning phobia many moons ago and was allotted a 9G '/' and a
> 1.4T 'home' (as well as swap the size of my ego), so find myself in a
> predicament similar to that of the OP.
> 
> (A recent thread seemed to imply that the installer's automagical
> partitioner for LVM leaves little or no empty room for growth, thus
> vitiating somewhat the very raison d'être of LVM at its root.)
> 

I think a lot of resizing issues have just gone away, as hard drive
manufacturers have been able to increase [affordable] drive size even
faster than Microsoft has expanded Windows.

I don't run a hard drive online for more than about five years,
retiring it to backup duty after that. The replacement drive is
normally twice the size, or larger, and the original drive was large
enough for me to have allocated massively more space than necessary. So
resizing is rarely necessary in the life of one of my drives, and can
easily be performed at the changeover.

LVM snapshots are another matter. Over the years, I've not had any bad
luck backing up live (home) systems using online copies, but I've always
taken what precautions I could to minimise risk. Snapshots are a much
safer way of doing this, and the performance hit while the shadow copy
is active can be kept to a fairly short time. It does require a
significant chunk of unallocated space, though in an emergency, an
external drive can be temporarily added.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#195965

On Mon, 21 May 2018 09:53:01 +0100 Joe said:

[--8<--]

> I don't run a hard drive online for more than about five years,
> retiring it to backup duty after that.

I run them in pairs (raid-1) until one of them gets down, where I retire the
other and get a new pair of replacement drives (once in more than 10 years).

It is true that with replacement period of more than 10 years, my disk space
requirements can exceed the drives at hand - theoretically. In practice, I
replaced my raid-1 pair with 2*750G in 2010 and 750G is still more than enough
for me.

I think this provides better protection against hardware issues, better
performance (due to parallel read logic of raid-1) and more cost effective.

Regards
-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [next] | [standalone]

#195976

On Mon, 21 May 2018 17:57:20 +0300 Abdullah Ramazanoğlu said:

> I run them in pairs (raid-1) until one of them gets down, where I retire the
> other and get a new pair of replacement drives (once in more than 10 years).

Forgot to add that in a raid-1 setup swap partition*s* should not be mirrored.
There should be 2 separate non-mirrored swap partitions, one on each drive, for
better swap performance (distributed I/O).

-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [next] | [standalone]

#195977

Le 21/05/2018 à 21:03, Abdullah Ramazanoğlu a écrit :
> 
> Forgot to add that in a raid-1 setup swap partition*s* should not be mirrored.

Of course they should be mirrored in RAID 1 too. Otherwise it defeats 
the purpose of RAID 1.

> There should be 2 separate non-mirrored swap partitions, one on each drive, for
> better swap performance (distributed I/O).

The purpose of RAID 1 is to provide redundancy and availability, not 
performance.
What do you think happens to a running system when one half of the swap 
suddenly becomes unavailable after a disk failure ?

[toc] | [prev] | [next] | [standalone]

#195978

On Mon, 21 May 2018 21:48:33 +0200 Pascal Hambourg said:

> Le 21/05/2018 à 21:03, Abdullah Ramazanoğlu a écrit :
> > 
> > Forgot to add that in a raid-1 setup swap partition*s* should not be
> > mirrored.  
> 
> Of course they should be mirrored in RAID 1 too. Otherwise it defeats 
> the purpose of RAID 1.
> 
> > There should be 2 separate non-mirrored swap partitions, one on each drive,
> > for better swap performance (distributed I/O).  
> 
> The purpose of RAID 1 is to provide redundancy and availability, not 
> performance.
> What do you think happens to a running system when one half of the swap 
> suddenly becomes unavailable after a disk failure ?

I would agree mirroring swap for a mission critical server. Otherwise it would
be an overkill, IMO.

If one of the non-mirrored swaps go down, then I will get a system crash. So?
Estimating once in a 15 years on average I would get a head-crash, this doesn't
justify (1) wasting disk space for mirrored swap, and (2) not taking advantage
of distributed swap I/O.

Though, RAID-1 read logic (of concurrent parallel I/O) partly compensates for
(2).

As for the purpose of RAID-1, there is theory and there is practice. It boosts
I/O performance, in addition to the advantages you mentioned.

Regards
-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [next] | [standalone]

#195980

On Mon, 21 May 2018 23:09:46 +0300 Abdullah Ramazanoğlu said:

> and (2) not taking advantage of distributed swap I/O.
> 
> Though, RAID-1 read logic (of concurrent parallel I/O) partly compensates for
> (2).

I forgot to mention that with mirrored swap, the mirrored *write* penalty
exceeds the *read* parallelization gains by RAID-1.

RAID-1 parallelizes only the read operations, while write ops are still
duplicated. With a swap bound system, your swap-write I/O doubles with mirrored
swap, choking both drives. Whereas with distributed (separate) swap partitions
you get a smooth swap-write distribution.

Regards
-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [next] | [standalone]

#195981

Le 21/05/2018 à 22:09, Abdullah Ramazanoğlu a écrit :
> On Mon, 21 May 2018 21:48:33 +0200 Pascal Hambourg said:
>>
>> The purpose of RAID 1 is to provide redundancy and availability, not
>> performance.
>> What do you think happens to a running system when one half of the swap
>> suddenly becomes unavailable after a disk failure ?
> 
> I would agree mirroring swap for a mission critical server. Otherwise it would
> be an overkill, IMO.
> 
> If one of the non-mirrored swaps go down, then I will get a system crash. So?

So you lose system availability. If you can stand this, then you don't 
need availability.

[toc] | [prev] | [next] | [standalone]

#195983

On Mon, 21 May 2018 23:18:50 +0200 Pascal Hambourg said:
> Le 21/05/2018 à 22:09, Abdullah Ramazanoğlu a écrit :

>> I would agree mirroring swap for a mission critical server. Otherwise it
>> would be an overkill, IMO.
>> 
>> If one of the non-mirrored swaps go down, then I will get a system crash.
>> So?  
> 
> So you lose system availability. If you can stand this, then you don't 
> need availability.

Although swap going offline causing "a system crash" was a bit of an
overstatement. More likely, some user space applications would crash, allowing
a graceful system shutdown - once in 15 years or so.

What is of primary value of using RAID-1 for me is protecting my data against
disk failures.

As for continuous system availability, yes I am willing to trade it a bit on a
non-critical system for better disk utilization and performance.

Regards
-- 
Abdullah Ramazanoğlu

[toc] | [prev] | [next] | [standalone]

#195999

Le 22/05/2018 à 00:12, Abdullah Ramazanoğlu a écrit :
> On Mon, 21 May 2018 23:18:50 +0200 Pascal Hambourg said:
>> Le 21/05/2018 à 22:09, Abdullah Ramazanoğlu a écrit :
> 
>>> I would agree mirroring swap for a mission critical server. Otherwise it
>>> would be an overkill, IMO.
>>>
>>> If one of the non-mirrored swaps go down, then I will get a system crash.
>>> So?
>>
>> So you lose system availability. If you can stand this, then you don't
>> need availability.
> 
> Although swap going offline causing "a system crash" was a bit of an
> overstatement. More likely, some user space applications would crash, allowing
> a graceful system shutdown - once in 15 years or so.
> 
> What is of primary value of using RAID-1 for me is protecting my data against
> disk failures.
> 
> As for continuous system availability, yes I am willing to trade it a bit on a
> non-critical system for better disk utilization and performance.

I understand that your use case does not require swap redundancy.
I hope that you also understand that other people may have stronger 
requirements and your statement about swap mirroring was wrong for them, 
thus wrong in general (what is not always right is wrong).

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web