On 01/09/2016 10:44, gevisz wrote: > 2016-09-01 10:23 GMT+03:00 Frank Steinmetzger <war...@gmx.de>: >> On Thu, Sep 01, 2016 at 08:13:23AM +0200, Alan McKinnon wrote: >> >>> it will take about 5 seconds to partition it. >>> And a few more to mkfs it. >>> >>> Are you sure you aren't thinking of mkfs with ext2 (which did take hours >>> for a drive that size? >> >> Some people do a full systems check (i.e. badblocks) before entrusting a >> drive with anything important. > > It is a good advice! I have already thought of this but I am sorry to > acknowledge > that, since the "old good times" of MS DOS 6.22, I never did this in Linux. :( > > And except for one 2.5" disk failure on my old laptop about 7 years ago, > I had no problem with this so far. :) > > All other my hard disks work for about 10 years without any intervention > from my side and even without any backups so far. That's why I started > to think about it now. :) > > So, can you, please, advice me about the program or utility that can do > badblocks check for me? > >>>> Is it still advisable to partition a big hard drive >>>> into smaller logical ones and why? >>> >>> The only reason to partition a drive is to get 2 or more >>> smaller ones that differ somehow (size, inode ratio, mount options, etc) >> >> If you want to do backups, then of course the file system is important, so >> it retains permissions and stuff. Your ext4 choice is the right one in that >> case. However, I partitioned by backupdrive into two partitions, so the one >> with the sensitive data can be encrypted. The big partition that holds media >> files has not got that treatment. > > It is, again, a good advice but, again, returning to the "old good times" > of MS DOS 6.22, I do remember that working then on 40MB (yes, megabytes) > hard drive I used some program that compressed all the data before saving > them on that hard drive. Unfortunately, one day, because of the corruption, > I lost all the data on that hard drive. Since then, I am very much afraid of > compressed or encrypted hard drives. > >>> Go with no partition table by all means, but if you one day find you >>> need one, you will have to copy all your data off, repartition, and copy >>> your data back. >> >> When I do the mentioned partitioning scheme, I put the biggest partition at >> the beginning of the drive and the smaller one(s) at the back. That way, >> should I ever actually need to resize a partition, I only have to export the >> smaller partition for the process (or none at all, if it’s just a backup >> itself and I have another backup on another drive). >> Of course there’s LVM these days, but up until recently, I used NTFS for the >> media partition so I could also read it in $DUMB_OS, which doesn’t know LVM. >> Only a short while back, I also switched to ext4 for that, so I can retain >> file names with : and ? in them. But I still refrained from using LVM, >> though. > > I am afraid of LVM because of the same reason I described above.
You are allowing your fears of 20 years ago to determine your present day attitudes. That's silly. There's a misconception that a drive is somehow a pristine storage device with pigeon holes where data goes and nothing below the fs level can have any effect. Nothing could be further from the truth. The sheer amount of encoding that goes into a drive is almost beyond belief. It is NOT a digital device, it is analog - exactly like tape, just many times more complex. It doesn't store bits, it stores fluctuating regions of local magnetism and all of that gets decoded by analog circuitry to represent digital bits. About 50% of your drive's capacity (measured by what the heads see) is devoted to marking where the tracks go, where the sectors start and end, checksumming and may other firmware safeguards. All that stuff can go wrong. Yes, encryption on-drive can go wrong. So can SSL traffic, gpg keys, encrypted mail, vpns and all your traffic over the internet (if you're on a corporate network I can almost assure you it's all encrypted inside an IPSec tunnel). That stuff doesn't break. Neither does your disk encryption. LVM can break, but it's really hard. All a PV is, is a block device with a 2k signature at the start then some metadata. All a VG is, is a bunch of PVs and some metadata to list them. An LV is really nothing more than an indirection lookup table: The fs knows which inode and sectors the file uses, and the LV has a mapping table to track which real disk sectors that is. The kernel does this all the time with every smidgen of RAM you have (it's how a vmm works). It's the same technology in essence. So yeah, stuff can break. But that same stuff is used in many other highly critical areas where you likely don't know of it, and that doesn't change that it's there. I know of know recent reports where disk encryption or volume management broke data solely due to a code bug in stable production versions. Devs are not that stupid :-) So honestly, your fears are baseless and have more to do with the chemical reactions inside your brain that reality. Sorry to be so blunt, but that's how it is. -- Alan McKinnon alan.mckin...@gmail.com
