Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] [OT] Is it still advisable to partition a big hard drive?
Date: Thu, 01 Sep 2016 09:44:57
Message-Id: a1c9b3c5-6e13-9bae-1bd5-9189a999eafc@gmail.com
In Reply to: Re: [gentoo-user] [OT] Is it still advisable to partition a big hard drive? by gevisz
1 On 01/09/2016 10:44, gevisz wrote:
2 > 2016-09-01 10:23 GMT+03:00 Frank Steinmetzger <Warp_7@×××.de>:
3 >> On Thu, Sep 01, 2016 at 08:13:23AM +0200, Alan McKinnon wrote:
4 >>
5 >>> it will take about 5 seconds to partition it.
6 >>> And a few more to mkfs it.
7 >>>
8 >>> Are you sure you aren't thinking of mkfs with ext2 (which did take hours
9 >>> for a drive that size?
10 >>
11 >> Some people do a full systems check (i.e. badblocks) before entrusting a
12 >> drive with anything important.
13 >
14 > It is a good advice! I have already thought of this but I am sorry to
15 > acknowledge
16 > that, since the "old good times" of MS DOS 6.22, I never did this in Linux. :(
17 >
18 > And except for one 2.5" disk failure on my old laptop about 7 years ago,
19 > I had no problem with this so far. :)
20 >
21 > All other my hard disks work for about 10 years without any intervention
22 > from my side and even without any backups so far. That's why I started
23 > to think about it now. :)
24 >
25 > So, can you, please, advice me about the program or utility that can do
26 > badblocks check for me?
27 >
28 >>>> Is it still advisable to partition a big hard drive
29 >>>> into smaller logical ones and why?
30 >>>
31 >>> The only reason to partition a drive is to get 2 or more
32 >>> smaller ones that differ somehow (size, inode ratio, mount options, etc)
33 >>
34 >> If you want to do backups, then of course the file system is important, so
35 >> it retains permissions and stuff. Your ext4 choice is the right one in that
36 >> case. However, I partitioned by backupdrive into two partitions, so the one
37 >> with the sensitive data can be encrypted. The big partition that holds media
38 >> files has not got that treatment.
39 >
40 > It is, again, a good advice but, again, returning to the "old good times"
41 > of MS DOS 6.22, I do remember that working then on 40MB (yes, megabytes)
42 > hard drive I used some program that compressed all the data before saving
43 > them on that hard drive. Unfortunately, one day, because of the corruption,
44 > I lost all the data on that hard drive. Since then, I am very much afraid of
45 > compressed or encrypted hard drives.
46 >
47 >>> Go with no partition table by all means, but if you one day find you
48 >>> need one, you will have to copy all your data off, repartition, and copy
49 >>> your data back.
50 >>
51 >> When I do the mentioned partitioning scheme, I put the biggest partition at
52 >> the beginning of the drive and the smaller one(s) at the back. That way,
53 >> should I ever actually need to resize a partition, I only have to export the
54 >> smaller partition for the process (or none at all, if it’s just a backup
55 >> itself and I have another backup on another drive).
56 >> Of course there’s LVM these days, but up until recently, I used NTFS for the
57 >> media partition so I could also read it in $DUMB_OS, which doesn’t know LVM.
58 >> Only a short while back, I also switched to ext4 for that, so I can retain
59 >> file names with : and ? in them. But I still refrained from using LVM,
60 >> though.
61 >
62 > I am afraid of LVM because of the same reason I described above.
63
64 You are allowing your fears of 20 years ago to determine your present
65 day attitudes. That's silly.
66
67 There's a misconception that a drive is somehow a pristine storage
68 device with pigeon holes where data goes and nothing below the fs level
69 can have any effect. Nothing could be further from the truth.
70
71 The sheer amount of encoding that goes into a drive is almost beyond
72 belief. It is NOT a digital device, it is analog - exactly like tape,
73 just many times more complex. It doesn't store bits, it stores
74 fluctuating regions of local magnetism and all of that gets decoded by
75 analog circuitry to represent digital bits. About 50% of your drive's
76 capacity (measured by what the heads see) is devoted to marking where
77 the tracks go, where the sectors start and end, checksumming and may
78 other firmware safeguards.
79
80 All that stuff can go wrong.
81
82 Yes, encryption on-drive can go wrong. So can SSL traffic, gpg keys,
83 encrypted mail, vpns and all your traffic over the internet (if you're
84 on a corporate network I can almost assure you it's all encrypted inside
85 an IPSec tunnel).
86
87 That stuff doesn't break. Neither does your disk encryption.
88
89 LVM can break, but it's really hard. All a PV is, is a block device with
90 a 2k signature at the start then some metadata. All a VG is, is a bunch
91 of PVs and some metadata to list them. An LV is really nothing more than
92 an indirection lookup table: The fs knows which inode and sectors the
93 file uses, and the LV has a mapping table to track which real disk
94 sectors that is.
95
96 The kernel does this all the time with every smidgen of RAM you have
97 (it's how a vmm works). It's the same technology in essence.
98
99 So yeah, stuff can break. But that same stuff is used in many other
100 highly critical areas where you likely don't know of it, and that
101 doesn't change that it's there.
102
103 I know of know recent reports where disk encryption or volume management
104 broke data solely due to a code bug in stable production versions. Devs
105 are not that stupid :-)
106
107 So honestly, your fears are baseless and have more to do with the
108 chemical reactions inside your brain that reality.
109
110 Sorry to be so blunt, but that's how it is.
111
112 --
113 Alan McKinnon
114 alan.mckinnon@×××××.com