Re: [PATCH 01/17] pramfs: documentation
On Fri, Jan 7, 2011 at 12:30 PM, Marco Stornelli wrote: > constraint). About the errors: pramfs does not maintain file data in the > page caches for normal file I/O, so no writeback, the read/write > operation are done with direct io and they are always sync. The data are > write protected in hw when the arch provide this facility (x86 does). > Inode contains a checksum and when there are problems they are marked as > bad. Superblock contains checksum and there is a redundant superblock. But you can still get pramfs inconsistencies if the system crashes at an inopportune moment. E.g. when making files you write the new inode to pramfs, and then you insert the entry into the directory. A crash between these two operations leaves an allocated inode that doesn't appear in any directory. Without a fsck option, it will be hard to see that you have this problem, and your only recovery option is to wipe *all* files by making a new filesystem. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/17] pramfs: documentation
Il 07/01/2011 19:42, Tony Luck ha scritto:
> On Thu, Jan 6, 2011 at 4:01 AM, Marco Stornelli
> 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).
Actually not (at least when strict devmem options is turned on) because
the memory region is marked exclusive at the moment (only a design
constraint). About the errors: pramfs does not maintain file data in the
page caches for normal file I/O, so no writeback, the read/write
operation are done with direct io and they are always sync. The data are
write protected in hw when the arch provide this facility (x86 does).
Inode contains a checksum and when there are problems they are marked as
bad. Superblock contains checksum and there is a redundant superblock.
> 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?
Yeah maybe the address book can be a case not perfectly suitable, but it
was only an example. I thought about the fs as a "cache" in this use
case. However the designer can use this area whatever he wants,
recently I saw in a project this fs used as a system cache for decrypted
files where the files were stored in flash encrypted, so I think it's
flexible.
> 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?
Sincerely in my embedded systems I've never used quotas even to save
footprint (for the kernel support I mean). I don't think it's an hot
feature in this case and other fs for embedded use as ubifs, jffs2 etc.
don't support it.
Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/17] pramfs: documentation
On Thu, Jan 6, 2011 at 4:01 AM, Marco Stornelli
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-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Move an assert under DEBUG_KERNEL.
On 01/06/2011 05:41 PM, Andrew Morton wrote:
+#ifdef CONFIG_DEBUG_KERNEL
#define ASSERT_RTNL() do { \
if (unlikely(!rtnl_is_locked())) { \
printk(KERN_ERR "RTNL: assertion failed at %s (%d)\n", \
@@ -789,6 +790,9 @@ extern void __rtnl_unlock(void);
dump_stack(); \
} \
} while(0)
+#else
+#define ASSERT_RTNL()
+#endif
static inline u32 rtm_get_table(struct rtattr **rta, u8 table)
{
Probably a worthwhile thing to do, IMO. If there's some net-specific
CONFIG_DEBUG_ setting then that wold be a better thing to use.
I looked and didn't find one. lib/Kconfig.debug has DEBUG_OBJECTS and
PROVE_LOCKING and such but nothing quite on topic. The only "DEBUG" in
net/Kconfig is NETFLITER_DEBUG. Nothing relevant in
drivers/net/Kconfig, there isn't a Kconfig in net/core...
I thought about adding a new symbol, but CONFIG_DEBUG_KERNEL is already
used in a few existing places:
arch/powerpc/kernel/sysfs.c
arch/parisc/mm/init.c
arch/blackfin/include/asm/entry.h
So this isn't the first instance of it, but that doesn't mean those uses
are correct. :)
However the patch was a) wordwrapped, b) space-stuffed and c) not cc'ed
to the networking list. So its prospects are dim.
Sorry, finally gave up on kmail and set up thunderbird. Still trying to
beat the darn thing into submission. (It looked right before I hit
send. And I cursored over the tabs to make sure. :)
I'll work out my email issues and then cc: the networking list on the
resubmit.
Thanks,
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
