Folks, 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. Jon.
--- Begin Message ---
- Subject: discard support in e2fsprogs and dm
- From: Jon Masters <jcm@xxxxxxxxxx>
- Date: Fri, 21 Oct 2011 01:18:13 -0400
- Organization: Red Hat, Inc.
Hey guys, 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. Jon.
--- End Message ---
_______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
