[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimGt5hi+TpFHWxktJEg3tcDQmmARdqFqzAt++OQ@mail.gmail.com>
Date: Fri, 7 Jan 2011 10:42:44 -0800
From: Tony Luck <tony.luck@...el.com>
To: Marco Stornelli <marco.stornelli@...il.com>
Cc: Linux Kernel <linux-kernel@...r.kernel.org>,
Linux Embedded <linux-embedded@...r.kernel.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
Tim Bird <tim.bird@...sony.com>
Subject: Re: [PATCH 01/17] pramfs: documentation
On Thu, Jan 6, 2011 at 4:01 AM, Marco Stornelli
<marco.stornelli@...il.com> wrote:
> +accessed data that must survive system reboots and power cycles. An
> +example usage might be system logs under /var/log, or a user address
> +book in a cell phone or PDA.
Some usage model questions:
How do you handle errors? I see that there are a few sanity checks in the
"mount" path ... but there would seem to be several opportunities for the
file system to get corrupted in other ways. Since you don't have a block
device, a standard "fsck" program looks challenging (though I guess you
could mmap("/dev/mem") to peek & poke at the filesystem before trying
to mount it). Some sort of recovery path would seem useful for the "address
book" use model ... or do you just expect users to back their address book
up (to the cloud?) and have the phone just make a clean filesystem if any
errors are found?
What about quotas? You have a fixed amount of persistent space, and
presumably a number of apps that the user installs on their device that
may like to use pramfs to store data. Do you need some kernel enforcement
to stop one rogue application from using up all the space? Or do you expect that
this would be handled in some library level interface that applications will
use to access pramfs?
-Tony
--
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