[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6934efce0809020944s36dd7f82wec77c4189ef1b114@mail.gmail.com>
Date: Tue, 2 Sep 2008 09:44:19 -0700
From: "Jared Hulbert" <jaredeh@...il.com>
To: "Geert Uytterhoeven" <Geert.Uytterhoeven@...ycom.com>
Cc: Linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
linux-mtd <linux-mtd@...ts.infradead.org>,
"Jörn Engel" <joern@...fs.org>,
tim.bird@...sony.com, cotte@...ibm.com, nickpiggin@...oo.com.au
Subject: Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
> I found what's wrong.
>
> The size of an AxFS image created by mkfs.axfs is always n*4096+4 bytes large.
> So when it wants to check the magic value in the last 4 bytes, the block layer
> tries to read a whole 512-byte sector, which fails for loop-mounted images.
>
> If you test on real FLASH, additional bytes after the end of the AxFS image can
> be read, hence it works.
>
> By padding the image with 508 zero bytes, I can mount it, on both PS3 (ppc64)
> and UML (ai32). I can even read images created on PS3.
Right. We haven't tested loopback since we added the magic end value.
How is one expected to read those last 4 bytes of a loopbacked file?
Are they unreadable? We can add the padding. I am just wondering if
this is a bug or a known limitation in the loopback handling or if
there is a different safer way of reading block devs with truncated
last blocks.
> However, there still are weird things going on, like `find' not seeing all
> files and directories, or just aborting, and `ls -lR' showing actual file
> contents in its output.
Do you see this behavior for all builds for just the PS3?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists