Second hard drive, very slow write.

[Jeremy_Ray]

If you

pwd
cd /home/yourname
pwd
ls -l

what is the output? "Total 0" or blank?

It wouldn't be able to go into /home/jeremy "jeremy" does not exist.

It's curious that it says it's root but I never had to log in to get there. I held down shift, picked recovery mode - and I'm root? No password?

[Snowhog]

It's curious that it says it's root but I never had to log in to get there. I held down shift, picked recovery mode - and I'm root? No password?

Yes.

[Jeremy_Ray]

Yes.

Isn't that a serious security issue?

[kubicle]

Isn't that a serious security issue?

Depends on the environment, but generally it's not much of a concern since anyone that has physical access to the machine basically has root access to it.

If you set a root password, the recovery mode will ask for it, but this doesn't really protect the machine unless several other steps are taken to secure the machine. For example, if you set a root password, anyone that can boot to grub can boot with init=/bin/bash to gain root access...if you also protect grub with a password, anyone can boot from external media to gain root access...if you disable booting from external media and protect bios with a password (to prevent re-enabling external boot), anyone with physical access can reset the bios etc.

It's a security risk (one you should be aware of), but it's basically an increased risk only if the machine is otherwise secured from physical access.

[SteveRiley]

One of the fundamental laws of computer security: If a bad guy has physical access to your machine, it isn't your machine anymore.

There's really only one mitigation against this: encryption. And it's important to realize that, like all other security measures, this mitigation simply increases the time between attack-start and successful attack-completion. Why do I mention this? Read on.

A safe carries a rating that indicates the strength of its protection. A one-hour safe is expected to withstand approximately one hour of attack by various devices. A six-hour safe has a much higher durability. A six-hour safe also costs a lot more. So as a purchaser of a safe, you make a risk tradeoff decision: you buy the maximum amount of protection you can, guided by two factors: (1) affordability and (2) an estimate of the value of its contents to you.

Computer security protection should be thought of in similar ways. It ought to be a crime for vendors to use words like "impossible," "unbreakable," "total security," and whatever else the marketing department might think of, for these claims are outright lies. Totally unbreakable security is a myth. If you ever find yourself in a position where you're evaluating computer security products and the vendors under consideration use language like this, I suggest you drop those vendors from your evaluation list. Deal only with those who are honest about their products' capabilities.

Given sufficient time and resources, all forms of encryption can and will eventually be broken. New and stronger forms will be invented. This is a fact. So should you stop using encryption? Absolutely not. 256-bit AES is, for now, sufficiently strong to withstand known attacks. It won't enjoy this forever, of course, which means the protection time window that it offers you will eventually close. By then, the cryptographic community will have moved on to newer and better algorithms.

[Jeremy_Ray]

I'm not looking at this from the perspective of stopping a Mission Impossible grade of adversary. I'm thinking about a shared-apartment-living kind of situation. When I was doing that, I had a BIOS password set and considered it sufficient for the guy I wanted to stop. Yeah, he could reset the bios, at a higher risk of getting caught in the act, or not putting things back in the right place and tipping me off that he'd been there. There's much less risk attached to using the shift key to get root.

Back on topic, I'm suspecting my SSD isn't as fast as it should be too. It seems like writes from GIMP to the SSD aren't fast enough. I'm not sure what I should be getting, but perhaps writing a 20 meg or smaller file should be instantaneous? It only takes a few seconds, but I can watch GIMP count up the megs as the file saves, in GIMP's save dialogue.

[kubicle]

I had a BIOS password set and considered it sufficient for the guy I wanted to stop.

That doesn't really mean much if you don't also set a grub password, anyone that can edit boot options in grub can get root access.

If you wish to prevent easily booting into recovery mode, you can either:
1. Set a root password (in which case it will be asked when booting to recovery), or
2. Remove the recovery mode option from grub menu by uncommenting #GRUB_DISABLE_RECOVERY="true" in /etc/default/grub and running 'sudo update-grub'...you can still boot to single mode to get to recovery mode by editing the boot options (which should be protected by a grub password), but it won't be available as a menu item.

Of course either method will still require setting up a grub password to be effective.

As discussed, this doesn't really 'secure' the machine, but it would add to the time and effort to get to root (as long as external booting is disabled and protected) in a way that'll likely keep your friends from booting to root semi-accidentally.

I'll let you get back on-topic now

[SecretCode]

Just to get back on topic ... I have no other ideas why the drive is so slow.

Are you able to try the same drive in a different computer? A different drive in the same computer?

[Jeremy_Ray]

I've made a bit of progress - the problem is definitely with Kubuntu 11.10. I ran Linux Mint 12 as a live cd and was able to copy nearly 6 gigs from the SSD to the HD in less than a minute. I rebooted into Kubuntu and randomly checked a few of the copied files, they're good.

The bug may be this one here - Link

I have also tried copying a 130 meg file from one part of the TB HD to another part of the TB HD. It took three minutes.

It looks like the only thing to do is continue to work around this problem until Pangolin comes out. Mint and Ubuntu both have show stopping bugs of their own (at least on my laptop), this one is not so bad by comparison.

[molecule-eye]

This bug is apparently still around in Kubuntu 13.04 (upgraded from 12.10), at least on my system. I have a 120GB SSD as primary/root/home drive and a 1TB storage drive, and copying 65MB from SSD to HDD took around a minute or so, which is ridiculously slow. I should really check to see if this is a problem with KDE or Kubuntu specifically.

[SteveRiley]

In /etc/fstab, add the noatime and discard mount options for each EXT4 partition you have. trim activates the kernel's SSD wear-leveling features, while noatime elimates the performance-killing update to a file's access time attribute. Recording access time for each and every read is unnecessary.

Here's my /etc/fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=fc16861b-bbd1-4c97-8d70-49839f97db83 /               ext4    [COLOR="#FF0000"]noatime,discard[/COLOR],data=writeback  0       1
# /boot/efi was on /dev/sda1 during installation
UUID=0B73-BB16  /boot/efi       vfat    defaults        0       1
# swap was on /dev/sda3 during installation
UUID=3a35c97c-71d2-4c78-861e-826f223ec6fa none            swap    sw              0       0
#
tmpfs  /tmp  tmpfs  noatime,mode=1777  0 0

Suggested modification in red.

[kubicle]

Recording access time for each and every read is unnecessary.

I'm repeating myself, but relatime (the current default) doesn't do that.

[SteveRiley]

I'm repeating myself, but relatime (the current default) doesn't do that.

Ah, I keep forgetting that's the default now!