least I don't see any lock that would prevent open while unlink is
in progress)...
And this.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
r one...
Ups, OK! Thanks again!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read t
es) {
if (TestSetPageLocked(page))
continue;
} else {
lock_page(page);
}
Yeah, thanks for the pointer! Thank you for your help on the issue!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list:
+ continue;
+
My only concern is - what if the page we skipped because of WB_SYNC_NONE_PG
will somehow loose its dirty TAG and will never be written-back? But it is
because of my poor knowledge of Linux MM internals. Could you please comment on
this?
Thanks!
--
m not sure, need to dig
these functions deeper, but they _seem_ to traverse the radix tree and change
tags, so marking one page dirty may need to change many tags, but again, I did
not really dig tis yet).
I'd appreciate any suggestions. Thanks!
--
Best Regards,
Artem Bityutskiy (Артём Битюцк
to use such
checks in ->unlink() for optimization?
P.S. the code and short description of the FS I refer is here:
http://www.linux-mtd.infradead.org/doc/ubifs.html
Thanks!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe l
fferently, I'd like to know if the inode is an orphan or not in
->unlink()?
AFAICS, if (inode->i_nlink == 0 && atomic_read(&inode->i_count) == 2) then this
file is not going to be an orphan. And AFAIC judge, it is safe to use this,
but I'm not sure and kindly ask f
trol
*wbc);
void sync_inodes(int wait);
/* writeback.h requires fs.h; it, too, is not included from here. */
--
1.5.0.6
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
and I do not believe this may happen. Why?
Could you or someone please give me a hint what exactly
inode->i_flags & I_LOCK protects? What is its relationship to i_mutex?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe
Andrew Morton wrote:
I'd have thought that a suitable wrapper around a suitably-modified
sync_sb_inodes() would be appropriate for both filesystems?
Hmm, OK, I'll try to do this. Thanks.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: sen
these LRU lists,
and I'd duplicate things.
Nevertheless, I add Teo on CC in a hope he'll give me some pointers.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
M
dest victims.
So I'm asking for ideas which would work and be acceptable by the
community later.
Thanks!
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
ar.
> I plan to do the torture test after this oobtest passed. And this
> nand_test suites are intended to integrated into our Blackfin
> uClinux-dist testsuites.
We are planning to clean up the tests and submit them for kernel
inclusion some day, when we have time.
--
Best regards,
The following are UBI changes I'd like to push to 2.6.24. The amount of
changes is small, so no additional comments.
URL: git://git.infradead.org/~dedekind/ubi-2.6.git master
(based on top of -rc2 for now).
Artem Bityutskiy (6):
UBI: fix sparse warnings
UBI: add more prints
ure test, but it is useful to run it with
limited amount of erase cycles to make sure your flash/driver survives
really high I/O load.For example, we caught occasional DMA transfer
problems while running the torture test for few days.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsu
operation? Does it have fixed position on flash? How large is it?
Thanks.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
On Wed, 2007-08-08 at 19:15 +0200, Jörn Engel wrote:
> On Wed, 8 August 2007 20:07:34 +0300, Artem Bityutskiy wrote:
> > On Wed, 2007-08-08 at 18:16 +0200, Jörn Engel wrote:
> > > +static inline void logfs_inc_count(struct inode *inode)
> > >
; +{
> + inode->i_nlink--;
> + mark_inode_dirty_sync(inode);
> +}
include/linux/fs.h: inode_inc_link_count() inode_dec_link_count() do
this. Although not sure they exist in the old kernel your patches are
against.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list:
me limit).
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
account free/dirty space in LogFS:
* When you need to write new data, how do you select the place where to
write?
* When you run out of space, how do select find the segment to
garbage-collect?
For any given segment (or eraseblock), how do you find amount of free
and dirty space in it?
--
From: Artem Bityutskiy <[EMAIL PROTECTED]>
Date: Tue, 7 Aug 2007 23:43:14 +0300
Subject: [PATCH] hexdump: use const notation
Trivial fix: mark the buffer to hexdump as const so callers could avoid
casting their const buffers when calling print_hex_dump().
The patch is really trivial
st u8 *ptr = buf;
int i, linelen, remaining = len;
unsigned char linebuf[200];
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
)
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Thanks for the catch, committed to UBI git tree.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
<[EMAIL PROTECTED]>
Committed, thank you!
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info
Linus Torvalds wrote:
On Wed, 18 Jul 2007, Artem Bityutskiy wrote:
please pull from upstream branch of
git://git.infradead.org/~dedekind/ubi-2.6.git to receive the following
updates:
Please don't hide the branch name in the free-flowing text, and instead
write your "please pull
/ubi/wl.c | 93 ++
include/mtd/ubi-header.h | 101 +
18 files changed, 403 insertions(+), 400 deletions(-)
Artem Bityutskiy (17):
UBI: fix memory leak in checking code
UBI: fix error path in create_vtbl
d.org/?p=ubi-2.6.git;a=summary
I plan to let dwmw2 pull them and send to Linus together with other
MTD/JFFS2 patches. If you have specific requests - go ahead.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> should manipulate the refcounts. Besides, ubi_get_device_info is an
> exported symbol which guarantees protection when accessed through
> symbol_get.
Yeah, looks fair, committed to UBI git, thanks.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this l
e no available EBs at which point it will refuse to work with the
> device.
My point is that instead of moving you should return error. You cannot
keep working with this device just because something really bad
happened, you do not know what, and you cannot react accordingly because
you do not know
On Tue, 2007-06-19 at 11:00 +0100, Richard Purdie wrote:
> On Tue, 2007-06-19 at 10:55 +0300, Artem Bityutskiy wrote:
> > On Mon, 2007-06-18 at 17:31 +0100, Richard Purdie wrote:
> > > + if (mtd->erasesize < OOPS_PAGE_SIZE)
> > > + erase.len = OOPS_PAGE_S
+ return ret;
> + }
> +
> + schedule(); /* Wait for erase to finish. */
> + remove_wait_queue(&wait_q, &wait);
> +
> + return 0;
> +}
Also, could you please use wait_event_interruptible() instead of
set_current_state() which looks better (indee
ormat the partition. So make a loop, skip bad
EBs and erase good ones. In case of erase failure (-EIO) mark the EB as
bad.
> +static int find_next_position(struct mtdoops_context *cxt)
> +{
> + struct mtd_info *mtd = cxt->mtd;
> + int page, maxpos = 0;
> + u32 count, maxcoun
est regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Satyam Sharma wrote:
Hi Artem,
On 5/30/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote:
Err, and important note is that it also wants this compressed data to be
independently uncompressable.
Hmm, okay.
But what I meant was that if jffs2's needs are "standard" enough i
Artem Bityutskiy wrote:
JFFS2 needs: it has _big_ input buffer, and _small_ output buffer, and
it wants
zlib to compress as much as possible from the input buffer, and make the
output
buffer full or nearly full of compressed data.
Err, and important note is that it also wants this compressed
e the output
buffer full or nearly full of compressed data.
This is why JFFS2 uses different hacks, but I do not remember details anymore.
Otherwise it could just use cryptoapi instead. In fact, I tried this 2
years ago, but gave up: http://lkml.org/lkml/2005/3/25/104
--
Best Regards,
Artem Bityu
y way to both shut up gcc, and also make the code less fragile
> for the long term.
Committed to the UBI git tree, thanks.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
simply
becomes __be16, etc - i.e. an integer type.
Err, what is the benefit of it? If we relied on sparce, why not would we be
just using __be16 directly?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Thu, 17 May 2007, Andrew Morton wrote:
Drat, and here was I hoping I'd lured you into implementing the generic
code.
Well, I am really happy to contribute, but I am not a generic janitor like
Cristoph, who (amaizingly) knows many differet kernel subsystems. I am
a specific developer and I w
friends. Thus, if I can do so, I will
just sit and wait for your decision - whether you include this patch to
-mm or not :-) .
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Thu, 2007-05-17 at 16:56 +0200, Christoph Hellwig wrote:
> On Thu, May 17, 2007 at 05:50:43PM +0300, Artem Bityutskiy wrote:
> > Christoph,
> >
> > On Thu, 2007-05-17 at 16:32 +0200, Christoph Hellwig wrote:
> > > Kill ubis homegrown endianess handling crap and re
e so assertive.
It is not a problem to fix this, but neither Rusty nor you explained
what is wrong with that call. But we _did_ explain why we use it. You
ignored the explanation and the questions.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the l
uld complain then?
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
; jefs
> > engelfs
> > poofs
> > crapfs
> > sweetfs
> > cutefs
> > dynamic journaling fs - djofs
> > tfsfkal - the file system formerly known as logfs
>
> Can we call it jörnfs? :)
And it is essential to preserve "ö" and let Pavel enjoy :-)
--
ilesystem ;-)
The problem is that JFFS2 will always be faster in terms of I/O speed
anyway, just because it does not have to maintain on-flash indexing
data structures. But yes, it is slow in mount and in building big
inodes, so the "faster" is confusing.
--
Best regards,
Artem Bity
Christoph Lameter wrote:
While we are at it: Fix bug in mtd/ubi/eba.c. Check was inverted.
Oh, thanks.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
liminates the memory leak by freeing buf before returning.
>
> Problem spotted by the Coverity checker.
It was already reported and fixed in our git tree. But thanks anyway.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe li
eraseblocks to si->corr, but the 5th _similar_
> case is ... just freed?
If we hit -EIO more then five times, there is probably something _really
bad_ with this MTD device and we _refuse_ attaching it. We return error,
and every data structure is freed. It does not matter if we add new_seb
a
d.org/?p=users/dedekind/ubi-2.6.git;a=commit;h=5125237efb6a3309fbf5b9a7a21aaf716787f2a2
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
t a known
> single time/location too.
I have 1 destroy location. And one exception where I allocate it
temporarily and destroy in the same function. And it is done only 2
times and only if one attaches un-formatted flash.
> I wish I could be more specific than this,
> but I've on
it's your
> call. Though it would be easier on you if you remove these exceptions
> that could be quite easily removed, actually.
I do not see any nice way to do this. If you suggest one, I will do.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: sen
ease be more specific.
I'll fix this shortly.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 2007-05-03 at 11:49 -0400, Florin Malita wrote:
> Coverity (CID 1614) spotted new_seb being dereferenced after kfree() in
> create_vtbl's write_error path.
Applied with minor trailing white-space cleanup, thanks.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsub
On Fri, 2007-04-27 at 09:00 -0700, Linus Torvalds wrote:
> On Fri, 27 Apr 2007, Artem Bityutskiy wrote:
> >
> > Linus, please, pull UBI tree from
> > git://git.infradead.org/ubi-2.6.git for-linus
> >
> > The UBI tree has been in -mm for several releases and w
360 +
include/mtd/ubi-user.h| 161
30 files changed, 12114 insertions(+), 0 deletions(-)
Artem B. Bityutskiy (1):
UBI: Unsorted Block Images
Artem Bityutskiy (3):
JFFS2: add UBI support
UBI: add me to MAINTAINERS
UBI: remove unused variable
c
Hello Adrian,
please, include this patch to your tree.
From 6f20d2abd85874658ef424ac46b79c43244d2274 Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy <[EMAIL PROTECTED]>
Date: Mon, 9 Apr 2007 14:23:48 +0300
Subject: [PATCH] trivial: s/i_sem /i_mutex/
This patch substitutes i_sem by i_mu
Adrian Bunk wrote:
This patch makes needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Thanks, will be fixed.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
in mainline
> (which comes down to JFFS2). LogFS works with every MTD device in
> mainline. The only combination that doesn't work is LogFS on UBI - due
> to deliberate design decisions on both sides.
You are welcome to discuss other irrelevant things to this thread.
--
Best r
received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм),
+ * Frank Haverkamp
+ */
+
+/*
+ * This file
received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+#ifndef __UBI_UBI_H__
+#define __UBI_UBI_H__
diff -auNrp tmp-from/drivers/mtd/Kconfig tmp-to/drivers/mtd/Kconfig
--- tmp-from/drivers/mtd/Kconfig2007-03-23 18:20:01.0 +0200
+++ tmp-to/drivers/mtd/Kconfig 2007-03-23 18:20:01.0 +0200
@@ -292,5 +292,7 @@ source "drivers/mtd/nand/Kconfig"
source "drivers/mtd/onenand/Kc
/linux/mtd/ubi.h | 191
include/mtd/Kbuild|2
include/mtd/mtd-abi.h |1
include/mtd/ubi-header.h | 360
include/mtd/ubi-user.h| 161 +++
30 files changed, 12039 insertions(+)
--
Best regards,
Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑ
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+/*
+ * This file includes implementation of UBI character device operations.
+ *
+ * There
copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ *
+ * Jan 2007: Alexander Schmidt, hacked per-volume
diff -auNrp tmp-from/fs/jffs2/fs.c tmp-to/fs/jffs2/fs.c
--- tmp-from/fs/jffs2/fs.c 2007-03-23 18:20:01.0 +0200
+++ tmp-to/fs/jffs2/fs.c2007-03-23 18:20:02.0 +0200
@@ -672,6 +672,13 @@ static int jffs2_flash_setup(struct jffs
return ret;
}
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+#ifndef __LINUX_UBI_H__
+#define __LINUX_UBI_H__
+
+#include
+#include
+#include
License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Authors: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ * Thomas Gleixner
+ * Frank Haverkamp
+ * Oliver Lohmann
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+/*
+ * This file contains implementation of volume creation, deletion, updating and
with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Authors: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм), Thomas Gleixner
+ */
+
+/*
+ * UBI wear-leveling unit.
+ *
+ * This unit is responsible for wear-leveling
License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм), Joern Engel
+ */
+
+/*
+ * This file includes implementation of fake MTD devices for each UBI
received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+/*
+ * This file includes volume table
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+/* This file mostly implements UBI kernel API functions */
+
+#include
+#include
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+/*
+ * Here we keep all the UBI debugging stuff which should normally be disabled
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+/* Here we keep miscellaneous functions which are used all over the UBI code
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+#ifndef __UBI_USER_H__
+#define __UBI_USER_H__
+
+/*
+ * UBI volume creation
copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+/*
+ * UBI input/output unit.
+ *
+ * This unit
+UNSORTED BLOCK IMAGES (UBI)
+P: Artem Bityutskiy
+M: [EMAIL PROTECTED]
+W: http://www.linux-mtd.infradead.org/
+L: [EMAIL PROTECTED]
+T: git git://git.infradead.org/ubi-2.6.git
+S: Maintained
+
MICROTEK X6 SCANNER
P: Oliver Neukum
M: [EMAIL PROTECTED]
-
To
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+/*
+ * UBI scanning unit.
+ *
+ * This unit is responsible for scanning the flash media
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Artem Bityutskiy (ÐиÑÑÑкий ÐÑÑÑм)
+ */
+
+/*
+ * The UBI Eraseblock Association (EBA) unit.
+ *
+ * This unit is responsible for I/O
zed that I should go further (e.g., dispose of per-unit data
structures), and started more re-work. Yes, I should have notified about
this new re-work, apologies.
Point taken, will be fixed :-)
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsu
ude LogFS into mainline.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
e counter difference is more then 4Ki (although it is tunable).
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majord
On Tue, 2007-03-20 at 21:36 +, David Woodhouse wrote:
> On Tue, 2007-03-20 at 22:05 +0200, Artem Bityutskiy wrote:
> > Guess why we still do not have a decent FTL? Because it is
> > _difficult_.
>
> No. We don't have a decent FTL because it's _pointless_. We&#x
or
> filesystem than there are people who have a basic background in flash
> devices.
Docs and FAQ will be improved, this is a question of time.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
his there. I mean, if one does not know much about the area,
and does not spend time to explore it, we cannot really help. But
anyway, we will try to write better docs, it just a question of time.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line &q
s inode, then VFS calls
read_inode() to satisfy JFFS2's iget() request. It is a _deadlock_
because the in read_inode JFFS2 will try to lock the above semaphores
again.
The wbuf recovery function has to be re-worked or just disabled -
because returning error is better then fall into a deadlock.
D
rm is to have the table on-flash (currently it is
in-ram which does not scale well).
Everything else will be folded together. No itsy-bitsy. I've almost
finished this re-structuring, doing bug-fixing.
P.S.: I'll let other folks to comment the other stuff.
--
Best regards,
Artem Bityutskiy (Б
not want to have, thus we go other way.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
aw block. So am I right that you assume that we
already have a decent FTL? The fact is that we do not.
Please, bear in mind that decent FTL is difficult and an FS on top of
FTL is slow, FTL hits performance considerably.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from
On Mon, 2007-03-19 at 14:54 -0500, Matt Mackall wrote:
> The issue is 14000 lines of patch to make a parallel subsystem.
It'll be much smaller after I remove "itsy-bitsy" and most of the
debugging stuff, in progress - wait for take 4.
--
Best regards,
Artem Bityutskiy (Бит
ck devices:
http://www.linux-mtd.infradead.org/faq/general.html#L_mtd_vs_hdd
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
ers.
OK, I'll look at this again, thanks.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-i
> - USB
> - virtualization
Please, rise this question in a separate thread, and discuss with
subsystem maintainers. I was directed here by the MTD maintainer.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
t; > + spin_unlock(&ubi->eba.eba_tbl_lock);
> > +
> > + return pnum;
> > +}
>
> Again, the locking seems pointless.
Thanks for comments, will be fixed.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "unsu
diff -auNrp tmp-from/drivers/mtd/ubi/wl.c tmp-to/drivers/mtd/ubi/wl.c
--- tmp-from/drivers/mtd/ubi/wl.c 1970-01-01 02:00:00.0 +0200
+++ tmp-to/drivers/mtd/ubi/wl.c 2007-03-14 17:15:50.0 +0200
@@ -0,0 +1,1761 @@
+/*
+ * Copyright (c) International Business Machines Corp., 2006
diff -auNrp tmp-from/drivers/mtd/ubi/vmt.c tmp-to/drivers/mtd/ubi/vmt.c
--- tmp-from/drivers/mtd/ubi/vmt.c 1970-01-01 02:00:00.0 +0200
+++ tmp-to/drivers/mtd/ubi/vmt.c2007-03-14 17:15:50.0 +0200
@@ -0,0 +1,360 @@
+/*
+ * Copyright (c) International Business Machines Cor
diff -auNrp tmp-from/fs/jffs2/fs.c tmp-to/fs/jffs2/fs.c
--- tmp-from/fs/jffs2/fs.c 2007-03-14 17:15:49.0 +0200
+++ tmp-to/fs/jffs2/fs.c2007-03-14 17:15:50.0 +0200
@@ -672,6 +672,13 @@ static int jffs2_flash_setup(struct jffs
return ret;
}
diff -auNrp tmp-from/drivers/mtd/ubi/scan.c tmp-to/drivers/mtd/ubi/scan.c
--- tmp-from/drivers/mtd/ubi/scan.c 1970-01-01 02:00:00.0 +0200
+++ tmp-to/drivers/mtd/ubi/scan.c 2007-03-14 17:15:50.0 +0200
@@ -0,0 +1,1478 @@
+/*
+ * Copyright (c) International Business Machines
diff -auNrp tmp-from/drivers/mtd/ubi/cdev.c tmp-to/drivers/mtd/ubi/cdev.c
--- tmp-from/drivers/mtd/ubi/cdev.c 1970-01-01 02:00:00.0 +0200
+++ tmp-to/drivers/mtd/ubi/cdev.c 2007-03-14 17:15:50.0 +0200
@@ -0,0 +1,926 @@
+/*
+ * Copyright (c) International Business Machines C
diff -auNrp tmp-from/drivers/mtd/ubi/misc.c tmp-to/drivers/mtd/ubi/misc.c
--- tmp-from/drivers/mtd/ubi/misc.c 1970-01-01 02:00:00.0 +0200
+++ tmp-to/drivers/mtd/ubi/misc.c 2007-03-14 17:15:50.0 +0200
@@ -0,0 +1,167 @@
+/*
+ * Copyright (c) International Business Machines C
601 - 700 of 813 matches
Mail list logo
