Installation fails on Crucial/Micron M225 256gb SSD

[RachaelB]

Have just installed a Crucial/Micron M225 256gb SSD with Indilinx "Barefoot" controller.

The installation of Kubuntu 9.10 from live CD and alternate CD fails (error: "/target is read only")
The installation of UNR 9.10 also fails
The installation of Kubuntu 9.04 from live cd fails.
The installation of Kubuntu 9.04 from alternate cd works ONLY IF the options for "guided using LVM" or "guided using LVM (Encrypted)" are used
The installation of OpenSUSE 11.1 fomr live cd works ONLY IF the "LVM" option is chosen

Don't know if this is relevant but... GParted and OpenSUSE both report the disk size as 238.47gb
Windows (eek!) which install with no problems also reports the disk size as 238.47gb
The Kubuntu and Ubuntu installers both report the disk size as the full 256.1gb

HELP?????? :-s

[RachaelB (8-launchpad-rlb-me)]

have just spent most of today on the phone to Crucial support.

Apprently the 256gb SDD drive does only have 238.47gb of usable space... so, therefore, my unit is fine.

What I'm guessing is that the installer disks are trying to partition to the declared 256.1gb and so are crashing when unable to access parts of the drive that they think are there, but arent really (if you see what I mean)

For some reason, the LVM approach overcomes this - though this doesnt work with the Kubuntu 9.10-alpha 4 alternate installation disc.

[RachaelB (8-launchpad-rlb-me)]

Might also be something to do with "partition balancing"???? Apparently this is required for SSD operation....

[kg (box-dev)]

What happens if you make your partitions yourself using fdisk/gparted before doing the installation? Afaik the alignment of partitions affects performance on SSDs but shouldn't make it not work at all.

[RachaelB (8-launchpad-rlb-me)]

it doesnt work, the installer cd still mis-represents the size of the partitions.

crucial support (us) also suggested using GParted to form a unformatted partition which could then be used. once again, doesnt work

the installation fails universally at one of 3 points:

(1) right at the beginning claiming that the *.deb packages are corrupted - they arent. the disc passes the check and install on a regular hdd
(2) at the installation of linux-x.x.xx-x-generic
(3) the installation of grub/grub2

how far you get in the installation depends upon how the disk has been manually configured.

the only way to complete the install is using the guided with logical volumes option.

setting up manually the exact same structure as the guided with lvm option still leads to the installation failing.

theres something seriously wrong here :(

[Colin Watson (cjwatson)]

Please do a test installation using the desktop (live) CD up to the point where it falls over, and then *before rebooting* attach these two files to this bug report:

  /var/log/syslog
  /var/log/partman

That should help us see what's going on in a bit more detail.

[RachaelB (8-launchpad-rlb-me)]

OK these are the install files for the 9.04 Kubuntu live cd. Hope they help.

On this occasion the error give was "/target/bin is read only" - which it isn't and there is nothing wrong with the SSD.

[RachaelB (8-launchpad-rlb-me)]

and here's the partition manager log

[RachaelB (8-launchpad-rlb-me)]

Ah-Ha!!!! now THAT'S interesting....

have just tried the install again from the 9.04 live CD, but this time with ext3 formatting instead of ext4 and its worked!!!!

So.... I guess the problem must lie either in the ext4 file system itself or the way the installer attempts to implement it....

And that's why I felt like I was hitting my head against a brick wall with both the live and alternate 9.10 CDs since they default to ext4

I hope I get a LOT of karma points for this! :)

Attached are the syslog and partman files for the successful ext3 installation

[RachaelB (8-launchpad-rlb-me)]

and the partman file for the successful installation...

told ya it wasnt my SSD lol

[Colin Watson (cjwatson)]

It does sort of look like an alignment issue (and the fact that LVM makes it work is very suggestive of this), but I agree that it's surprising that that would make it not work at all. I don't have a quick answer for you, but since this is important for performance on other SSDs anyway I hope that we can do something about it for 9.10.

[RachaelB (8-launchpad-rlb-me)]

hi colin

thnkyou SO much for looking at this - i'm very relieved to know that i'm definitely not going round the twist!

the only other information i think i can give you which may help are the attached 2 photographs. the first is a shot of how GParted sees the disk structure of a successful ext3 based LVM installation. the second is how the installation disc partition manager sees the same drive.

it was this misrepresentation of the drive size by the partition manager that first gave me a clue as to what was happening. if it makes you feel any better, this isnt just a *buntu problem, it also afftects OpenSUSE and Debian (to my knowledge)

[RachaelB (8-launchpad-rlb-me)]

and this is the partition manager screen photo...

[Colin Watson (cjwatson)]

The size difference is actually a red herring, and nothing to do with this bug. GParted shows sizes in binary units (note the "i" in "GiB" after the number) - a GiB is 1024 * 1024 * 1024 bytes. The installer's partitioner, partman, shows sizes in decimal units (GB) - a GB here is 1000 * 1000 * 1000 bytes. The reason for this choice in partman, which might seem counterintuitive at first, is that disk manufacturers have a very long-standing bad habit of quoting sizes in decimal units to make their disks sound bigger, and where possible we'd rather show sizes that match what the manufacturer advertises because that cuts down on questions of the form "why doesn't the installer see all the space on my disk?".

I'd tend to argue that gparted should do the same, but I'm not much involved in its maintenance.

[RachaelB (8-launchpad-rlb-me)]

OK... problem solved (at least, sort of...)

the installation failure is entirely to do with the ext4 file system. using ext3 gives no problems whatsoever. this is irrespective of whether or not the ssd is correctly balanced.

the correct balancing for a 128k erase block ssd (most ssd but not ocz) is to use fdisk to create a geometry of:

~# fdisk -H 8 -S 32 /dev/sda(x)

the first partition should then be alligned (ie started on) block 5.
all other partitions are then automatically aligned.

formatting should take place with:
~# mke2fs -t ext3 -E stripe-width=32 /dev/sda(x)

if logical volumes are used the metadata should be increased in size from 192k to 256k to keep things aligned on 128k boundaries using:

~# pvscreate --metadatasize 250k /dev/sda(x)
(don't know why 250k, but using 256k gives a meta-data size of 320K!)

however, like i say - the problem rests entirely with ext4 (or, at least, the package installer's implementation of it)

hope this helps!

[Colin Watson (cjwatson)]

Thanks for that! That doesn't look *too* bad, so I'll see what I can do
to get something similar integrated.

Could you attach a tarball of /sys/block/sda/, just so that I can make
sure to get the detection code right?

[Colin Watson (cjwatson)]

Hi Rachael,

Did you get a chance to get the tarball of /sys/block/sda/ that I asked for? I'll need that to make sure I get the code right, I think.

[RachaelB (8-launchpad-rlb-me)]

Hi Colin,

So sorry for the delay - been up to my neck in work and kind of forgot about your request.
Anyway, attached is the sda folder - I hope it helps you.

As I said before tho, the problem doesn't appear to the balancing of the ssd itself.
The problem definitely resides with the implementation of the ext4 file system - does it use "unusual" s-ata commands that arent used by ext3? Any installation will work providing that ext3 is used.

ext3 will work for the ssd irrespective of whether or not the drive is correctly balanced.

The only advantage to defining the drive as -S 32 -H 8 is that all boundaries (apart from the first partition) will automatically be aligned on a 128k basis. As you will see from the attached files, my partition sda1 has been set up for the data to start at 1024, thereby negating the "first track" problem.

If extended partitions are used then the amount of space for the meta-data should be increased to 256k from the standard 192k in order to keep to the 128k multiple boundaries (thanks to Ted Tso for that one!).

I don't think that defining the raid stripe-width at 32 makes any difference, although I could be proven wrong on this point.

OCZ drives, I believe, use a stripe width of 512k rather than the 128k used by other manufacturers. For those drives the allignment would be slightly different.

For the reference books, I've also elected to mount the partitions using noatime in order to reduce the number of writes to the drive.
Also in /etc/laptop-mode/laptop-mode.conf it's possible to specify a spin down time of "1" since there are no delays with a ssd and no wear/tear involved in continually spinning up/down the drive. Also the amount of readahead has been set to 128k (the same as nolm) once again to reduce the amount of data read from the drive, hopefully thereby extending it's life slightly.

I really hope all this helps somehow.

If I can be of any further help to you, please don't hesitate to email.

Rachael

[RachaelB (8-launchpad-rlb-me)]

P.S. Please let me know if you think I've messed up the maths somewhere and got the geometry wrong! :(

[Vishal Rao (vishalrao)]

(posting this related, if not similar, issue as an FYI)

Folks, my problems are solved with Lucid 10.04 (alpha 2) and workarounds - it looks like an NCQ issue, please go through the following links/posts/threads:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/502219/comments/7
http://ubuntuforums.org/showpost.php?p=8690795&postcount=16

In short, pass the " libata.force=noncq " kernel boot option or hopefully fix upstream with those lines to blacklist the crucial models which don't work (maybe other brands/models too?)

[Ralph Ulrich (eulenreich)]

Rachael wrote:
> formatting should take place with:
> ~# mke2fs -t ext3 -E stripe-width=32 /dev/sda(x)

??

But due to man mkfs.ext3:

stripe-width=stripe-width
                      Configure the filesystem for a RAID array with stripe-width filesystem blocks per stripe.
                      This is typically stride-size * N, where N is the number of data-bearing disks in the RAID
                      (e.g. for RAID 5 there is one parity disk, so N will be the number of disks in the array
                      minus 1). This allows the block allocator to prevent read-modify-write of the parity in a
                          RAID stripe if possible when the data is written.

But:
stride=stride-size
                Configure the filesystem for a RAID array with stride-size filesystem blocks. This is the
                number of blocks read or written to disk before moving to the next disk, which is sometimes
                referred to as the chunk size. This mostly affects placement of filesystem metadata like
                bitmaps at mke2fs time to avoid placing them on a single disk, which can hurt performance.
                 It may also be used by the block allocator.

[RachaelB (8-launchpad-rlb-me)]

Only quoting the fabled Ted Tso on that one :) personally I don't think it makes much difference!
-----Original Message-----
From: Ralph Ulrich <email address hidden>
Date: Wed, 17 Mar 2010 20:51:48
To: <email address hidden>
Subject: [Bug 415888] Re: Installation fails on Crucial/Micron M225 256gb SSD

Rachael wrote:
> formatting should take place with:
> ~# mke2fs -t ext3 -E stripe-width=32 /dev/sda(x)

??

But due to man mkfs.ext3:

stripe-width=stripe-width
                      Configure the filesystem for a RAID array with stripe-width filesystem blocks per stripe.
                      This is typically stride-size * N, where N is the number of data-bearing disks in the RAID
                      (e.g. for RAID 5 there is one parity disk, so N will be the number of disks in the array
                      minus 1). This allows the block allocator to prevent read-modify-write of the parity in a
                          RAID stripe if possible when the data is written.

But:
stride=stride-size
                Configure the filesystem for a RAID array with stride-size filesystem blocks. This is the
                number of blocks read or written to disk before moving to the next disk, which is sometimes
                referred to as the chunk size. This mostly affects placement of filesystem metadata like
                bitmaps at mke2fs time to avoid placing them on a single disk, which can hurt performance.
                 It may also be used by the block allocator.

--
Installation fails on Crucial/Micron M225 256gb SSD
https://bugs.launchpad.net/bugs/415888
You received this bug notification because you are a direct subscriber
of the bug.

Status in “parted” package in Ubuntu: Triaged
Status in “parted” source package in Karmic: Triaged

Bug description:
Have just installed a Crucial/Micron M225 256gb SSD with Indilinx "Barefoot" controller.

The installation of Kubuntu 9.10 from live CD and alternate CD fails (error: "/target is read only")
The installation of UNR 9.10 also fails
The installation of Kubuntu 9.04 from live cd fails.
The installation of Kubuntu 9.04 from alternate cd works ONLY IF the options for "guided using LVM" or "guided using LVM (Encrypted)" are used
The installation of OpenSUSE 11.1 fomr live cd works ONLY IF the "LVM" option is chosen

Don't know if this is relevant but... GParted and OpenSUSE both report the disk size as 238.47gb
Windows (eek!) which install with no problems also reports the disk size as 238.47gb
The Kubuntu and Ubuntu installers both report the disk size as the full 256.1gb

HELP?????? :-s

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/ubuntu/+source/parted/+bug/415888/+subscribe

[Ralph Ulrich (eulenreich)]

with
mke2fs -t ext3 -E stripe-width=32 /dev/sda(x)
you attempt using 32 disks . You probably mean:
mke2fs -t ext3 -E stride=32 /dev/sda(x)

[Phillip Susi (psusi)]

This looks like the drive is rejecting IO requests that are not 4kb aligned, which causes the journal to fail into read only mode.

Can you post the output of the following 3 commands:

sudo hdparm -I /dev/sda
sudo dd bs=512 count=1 iflag=direct of=/dev/null if=/dev/sda
sudo dd bs=512 count=1 iflag=direct of=/dev/null if=/dev/sda skip=1

[Vishal Rao (vishalrao)]

What can you glean from the output of those three commands? I'm posting mine here too FYI.

[Vishal Rao (vishalrao)]

Note I've had problems with my 128gb model on an Intel mobo, so I need to, to this day, specify the "libata.force=noncq" kernel boot option for things to apparently become smooth :-)

[Phillip Susi (psusi)]

Some comments seem to indicate that the problem is due to alignment, and some due to ncq. If it is an alignment issue that should be fixed since partitions are now alined to 1 MiB by default. If it is an ncq issue, then it's not a bug in parted, but a hardware defect that may be worked around with a kernel quirk.

Can anyone test this with all 4 permutations of alignment and libata.force=noncq? I wonder if it is the combination of alignment and ncq that triggers the problem, and thus either fixing the alignment or disabling ncq works around it.

[Launchpad Janitor (janitor)]

[Expired for parted (Ubuntu) because there has been no activity for 60 days.]