[nSLUG] Debian Wheezy partitioning...

Rory rory at unixism.org
Sun Oct 19 17:40:48 ADT 2014


It's funny how ineffective it is to encrypt your HD after it's stolen or 
lost :)

I encrypt almost every disk in my possession except in cases where 
performance is a must rather than a nice-to-have. It's also absolutely 
mandatory where I work.

On 14-10-19 05:25 PM, Oliver Doepner wrote:
> I will hang my head in shame once my laptop has actually been stolen. ;o)
> I usually only use it at home and have never been a burglary victim in 
> my life (40+ years).
>
> On Sun, Oct 19, 2014 at 3:37 PM, Rory <rory at unixism.org 
> <mailto:rory at unixism.org>> wrote:
>
>     I know I'm late to this thread but I'll make another plug for
>     LVM2. The learning curve isn't too steep and the advantages make
>     it worthwhile. Plus, we're all supposed to like learning new Linux
>     tech :)
>
>     Even on a single disk system the flexibility has saved my butt a
>     few times; well it has saved me significant time at least. On a
>     multi-disk or raid system the advantages are multiplied. The full
>     stack of RAID + LVM2 might seem thick when you're setting it up
>     but I'll never setup a file server any other way again.
>
>     Also if you use the 'full drive encryption' with recent distro
>     versions (which you always do on a laptop, yes? no? hang your head
>     in shame! :) ) then you're using LVM2 already.
>
>     - R
>
>
>     On 14-10-03 08:21 PM, Oliver Doepner wrote:
>>     - Ok, interesting that modern LVM2 overhead is low. Anyhow, I
>>     don't like the added complexity (call me mentally lazy) if I
>>     don't absolutely need it.
>>
>>     - Corrupt sectors are probably a sign to replace the whole drive,
>>     and on a single drive system like laptop that means a reinstall
>>     anyway. I use a file server on the home network with automated
>>     backups to external disk (cron + rsync) to protect more precious
>>     data.
>>
>>     - Regarding different filesystems: I use XFS for everything. I
>>     haven't noticed any problems for big or small files.
>>
>>     - I like Debian and almost never install other distros. If I do I
>>     use a Live CD first, but usually don't want it to access my
>>     /home. My experience with other distros: Not enough momentum and
>>     developer base to be as solid and well thought-out as Debian.
>>
>>     On Fri, Oct 3, 2014 at 12:57 AM, Dave Flogeras
>>     <dflogeras2 at gmail.com <mailto:dflogeras2 at gmail.com>> wrote:
>>
>>         On Thu, Oct 2, 2014 at 10:16 PM, Oliver Doepner
>>         <odoepner at gmail.com <mailto:odoepner at gmail.com>> wrote:
>>         > I heard LVM has significant overhead and is too complicated for my taste.
>>
>>         Perhaps in the early days of LVM.  I have not noticed any
>>         difference
>>         on any of my machines that have migrated to modern LVM2.  As
>>         far as I
>>         understand, even without it, the kernel does translations between
>>         user-space, drivers, and the block devices (just like it does
>>         between
>>         a process' virtual memory and the machine's physical
>>         memory).  LVM is
>>         just incorporated into this "table lookup" at the kernel
>>         level.  The
>>         CPU can manipulate a pointer far quicker than most storage
>>         systems can
>>         read a block of disk.
>>
>>         I know a lot of people have written about slow performance
>>         while using
>>         snapshots.  I only let snapshots live for the duration of a
>>         backup,
>>         and for my uses some degradation is acceptable to get a
>>         consistent
>>         backup.  I think some people use snapshots as a way to trying
>>         out new
>>         software installations with the option to revert.  Their
>>         performance
>>         suffers until they merge or discard the snapshot.
>>
>>
>>         > Can anyone think of drawbacks of this single partition
>>         approach?
>>
>>         Disadvantages might include:
>>         - A bad block causing filesystem corruption might lead to
>>         more damage
>>         - You cannot take advantage of different filesystem strengths for
>>         different types of data.  For instance, I use reiserfs for
>>         situations
>>         when I know I will have many many <4k files (development trees,
>>         Gentoo's package manager,  etc.).  I use ext4 when I will
>>         have lots of
>>         big files, or do processing on batches of large files
>>         (benchmarking
>>         showed a marked improvement).
>>         - With separate /home and/or other user data partitions, you can
>>         easily install a new distro without wiping the whole disk and
>>         copying
>>         your data around (although doing this without working backups
>>         is a bad
>>         idea in any situation).
>>
>>         There are many good points on pro/con multiple partitions
>>         here, as
>>         usual there is no right answer; it depends on your own situation:
>>
>>         http://en.wikipedia.org/wiki/Disk_partitioning
>>
>>
>>         Dave
>>         _______________________________________________
>>         nSLUG mailing list
>>         nSLUG at nslug.ns.ca <mailto:nSLUG at nslug.ns.ca>
>>         http://nslug.ns.ca/mailman/listinfo/nslug
>>
>>
>>
>>
>>     -- 
>>     Oliver Doepner
>>     http://doepner.net/
>>
>>
>>     _______________________________________________
>>     nSLUG mailing list
>>     nSLUG at nslug.ns.ca  <mailto:nSLUG at nslug.ns.ca>
>>     http://nslug.ns.ca/mailman/listinfo/nslug
>
>
>     _______________________________________________
>     nSLUG mailing list
>     nSLUG at nslug.ns.ca <mailto:nSLUG at nslug.ns.ca>
>     http://nslug.ns.ca/mailman/listinfo/nslug
>
>
>
>
> -- 
> Oliver Doepner
> http://doepner.net/
>
>
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/mailman/listinfo/nslug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/pipermail/nslug/attachments/20141019/9a20ddf1/attachment-0001.html>


More information about the nSLUG mailing list