On Thu, 2008-02-14 at 17:16 -0500, Erez Zadok wrote:
> Hi David,
>
> This has been a problem I've seen for a while. I've generated a jffs2 image
> of an empty directory (I don't recall the version of the jffs2 utils I've
> used to generate it). I mount the jffs2 image something like this:
>
>
On Wed, 2007-07-11 at 13:35 +0200, Christoph Hellwig wrote:
> On Tue, Jul 10, 2007 at 01:31:52AM -0700, Andrew Morton wrote:
> > romfs-printk-format-warnings.patch
>
> NACK on this one.
The rest of it is nacked anyway, until we unify the point and
get_unmapped_area methods of the MTD API.
--
d
On Tue, 2007-06-05 at 20:49 +0200, Segher Boessenkool wrote:
> >>> It would be better if GCC had a 'nopadding' attribute which gave us
> >>> what we need without the _extra_ implications about alignment.
> >>
> >> That's impossible; removing the padding from a struct
> >> _will_ make accesses to it
On Tue, 2007-06-05 at 17:49 +0200, Segher Boessenkool wrote:
> > It would be better if GCC had a 'nopadding' attribute which gave us
> > what we need without the _extra_ implications about alignment.
>
> That's impossible; removing the padding from a struct
> _will_ make accesses to its members u
On Mon, 2007-06-04 at 10:54 +0200, Jörn Engel wrote:
> There is no particular reason. '3' should be a reasonable value for
> most people. If actual users want to change this value, I can make it
> a mount option as well. Right now I'm just lazy and doubt the merits.
I think you probably made th
On Mon, 2007-06-04 at 11:12 +0200, Jörn Engel wrote:
> On Sun, 3 June 2007 23:42:25 +0200, Arnd Bergmann wrote:
> > On Sunday 03 June 2007, Jörn Engel wrote:
> > > +struct logfs_je_spillout {
> > > + __be64 so_segment[0];
> > > +}__packed;
> >
> > All the on-disk data structures you define
s too, but those are very minor. If you
insist, I could redo the history to omit them, but it's probably cleaner
not to.
Artem Bityutskiy (1):
[JFFS2] Fix buffer length calculations in jffs2_get_inode_nodes()
David Howells (1):
[MTD] generalise the handling of MTD-specific superbloc
On Fri, 2007-05-18 at 08:17 +0200, Jan Engelhardt wrote:
> > AFAIK, the camera stops writing to the flash card and automatically
> > turns off when it's low on battery (before empty).
>
> But then, one should also consider the case where a cam is connected to
> AC and someone inadvertently trips o
On Thu, 2007-05-17 at 09:12 +, Pavel Machek wrote:
> Nah, it would lead to Jorn disappearing misteriously and _Pavel_
> accused of murder ;-).
Are you suggesting that you would murder Jörn (you misspelled his name)
merely for the heinous crime of using his own name?
Your Luddism was already q
On Thu, 2007-05-17 at 17:20 +0900, Dongjun Shin wrote:
> There are, of course, cases where direct access are better.
> However, as the demand for capacity, reliability and high performance
> for the flash storage increases, the use of FTL with embedded controller
> would be inevitable.
>
> - The c
On Thu, 2007-05-17 at 15:12 +0900, Dongjun Shin wrote:
> The current trend of flash-based device is to hide the flash-specific details
> from the host OS. The flash memory is encapsulated in a package
> which contains a dedicated controller where a small piece of software (F/W or
> FTL)
> runs and
On Wed, 2007-05-16 at 08:34 -0700, Andrew Morton wrote:
> Reduced testability, mainly. Also potentially reduced usefulness.
CONFIG_MTD has never been a barrier to testability. JFFS2 depends on MTD
and had _most_ of its early testing and development done on the 'fake'
mtdram device.
Utility is a
On Wed, 2007-05-16 at 15:53 +0200, Jörn Engel wrote:
>
> My experience is that no matter which name I pick, people will
> complain
> anyway. Previous suggestions included:
> jffs3
> jefs
> engelfs
> poofs
> crapfs
> sweetfs
> cutefs
> dynamic journaling fs - djofs
> tfsfkal - the file system form
On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote:
> The start and end points passed to block_prepare_write() delimit the region of
> the page that is going to be modified. This means that prepare_write()
> doesn't need to fill it in if the page is not up to date.
Really? Is it _really_ goi
On Tue, 2007-05-15 at 13:37 -0700, Andrew Morton wrote:
> But it includes an MTD header file.
>
> Can this code be tested by people who don't have MTD hardware? We used to
> ahve a fake-mtd-on-a-blockdev thing, whcih was in a state of some
> disrepair. Maybe it got repaired. Or removed. I can'
On Tue, 2007-05-15 at 21:19 +0200, Jörn Engel wrote:
> On Tue, 15 May 2007 15:07:05 -0400, John Stoffel wrote:
> >
> > I've been semi watching this, and the only comment I really can give
> > is that I hate the name. To me, logfs implies a filesystem for
> > logging purposes, not for Flash hardwa
On Wed, 2007-04-11 at 19:49 -0700, Nate Diller wrote:
> Replace jffs2_gc_fetch_page() and jffs2_gc_release_page() using the
> read_cache_page() and put_kmapped_page() calls, and update the call site
> accordingly. Explicit calls to kmap()/kunmap() make the code more clear.
>
> Signed-off-by: Nate
On Sat, 2007-03-17 at 01:09 +, Christoph Hellwig wrote:
> This touches all nfs exporting filesystems, and I've done testing
> on all of the filesystems I have here locally (xfs, ext2, ext3,
> reiserfs, jfs)
modprobe mtdram ; mount -tjffs2 mtd0 /mnt
:)
--
dwmw2
-
To unsubscribe from this l
On Tue, 2006-12-12 at 07:06 -0600, Josh Boyer wrote:
> On 12/12/06, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > Josh Boyer wrote:
> > > On 12/12/06, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > >> I have created the 'kill-jffs' branch of
> > >> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/mis
On Thu, 2005-07-07 at 11:10 -0700, Greg KH wrote:
> Yes, and then I change namespaces to put /etc/shadow at
> /foo/baz/etc/shadow and then access it that way? Will the current
> audit system fail to catch that access?
The watch is attached to the inode which you happened to call '/etc' in
your na
On Thu, 2005-07-07 at 08:40 +0200, Arjan van de Ven wrote:
> why is this? It would be a very logical thing to store this stuff inside
> the inode. It sounds like a bad design to keep per inode data out of the
> inode. (if you're concerned about taking a lot of space, put a pointer
> to a kmalloc()'
On Wed, 2005-03-02 at 08:43 +, Anton Altaparmakov wrote:
> > I thought we declared that the concurrent clear_inode() and read_inode()
> > were a VFS bug, and fixed it? It's even fixed in 2.4 now isn't it?
>
> Is it? I must have missed this discussion. )-:
Wasn't that why we backported __wai
On Mon, 2005-02-14 at 20:44 +, Anton Altaparmakov wrote:
> So every time we get a concurrent clear_inode() and iget() for the same
> inode what happens? We get your "Failed to get bitmap attribute." every
> time? Or can clear_inode only be called once the inode is removed from
> icache?
[EMAIL PROTECTED] said:
> Now, a good way to force the issue may be to just remove the "ioctl"
> function pointer from the file operations structure altogether. We
> don't have to force peopel to use "read/write" - we can just make it
> clear that ioctl's _have_ to be wrapped, and that the only i
[EMAIL PROTECTED] said:
> I can tell you haven't had to write any 32-bit ioctl emulation code
> for a 64-bit kernel recently.
If that had been done right the first time, you wouldn't have had to either.
For that matter, it's often the case that if the ioctl had been done right
the first time, n
25 matches
Mail list logo