Can you share the setup procedure for those interested?
Jon Masters <jcm(a)redhat.com> schrieb:
>In case anyone is interested, I have Fedora running on the AC100U now.
>Unlike some of the other hacks I've seen I wanted to actually use the
>storage efficiently with device mapper presenting it as a contig. block
>device. Unfortunately, some of the block discard support seems to be
>tripping that up. If you try an AC100 with dm, make sure you specify "-E
>nodiscard" to mkfs.ext4 during filesystem creation.
>I'm trying to get a Fedora 15 ARM netbook with a builtin eMMC (looks
>like an SSD, it's not really) working at the moment. If you're
>interested, is a Toshiba AC100U that originally comes with Android and a
>very weird partition table layout used by Android that is both custom,
>not replaceable (bootloader restores it always on reset to the 14
>different partitions that it would like there to be, and several of them
>are unwriteable and not seen by the kernel, etc. etc.), etc. So I'm
>stuck with a couple of small partitions and one big one. A natural case
>where I might aswell use dm to present one backing device for ext4.
>Blah blah blah. Anyway. Long story short, I can make a filesystem on
>this, but only if I specifically disable discard during mkfs. If I let
>that happen, we sit in 100% CPU waiting on that ioctl that never
>completes. Before I dig into this for curiosity, I noticed that you had
>spoken about this a while back, so I wonder if you have some pointers.
>It's an older kernel (currently 2.6.38 but there should be something
>newer soon, so clearly this is not something I'd want to generally worry
>about for upstream) but after the dm discard stuff got merged. Do we try
>to detect whether to call for BLKDISCARD or is this always done now?
>Any thoughts? I'm sorry I'm not a block layer debug expert but I'll
>otherwise put this to one side until there's a more recent kernel.
>arm mailing list
Show replies by date