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:
# cp
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.
--
dwmw2
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 its members
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
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 in this file
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 the
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 superblocks
David Woodhouse (4):
[JFFS2] Fix BUG() caused by failing to discard xattrs
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 on the
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 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
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
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't
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_ going
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 formerly known
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 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 hardware with
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
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/misc-2.6.git that
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()'d
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
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
[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,
[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 ioctl's
24 matches
Mail list logo
