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 |