Jens Axboe wrote:
On Sat, Jun 02 2007, Tejun Heo wrote:
Hello,
Jens Axboe wrote:
Would that be very different from issuing barrier and not waiting for
its completion? For ATA and SCSI, we'll have to flush write back cache
anyway, so I don't see how we can get performance advantage by
I am not sure there really is a best list for this, but this is the
closest I can think of.
I am working on host software, for a series of cards
(www.picocomputing.com)
All of these cards have an FPGA, most have a processor, memory,
flash and other resources.
They have different
On Sun, 3 June 2007 23:58:43 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+#define COMPR_LEVEL 3
+
+static DEFINE_MUTEX(compr_mutex);
+static struct z_stream_s stream;
Is there a particular reason to choose '3' as the only compression
level? Should this
On Mon, 4 June 2007 00:07:36 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+static long decay(long t0, long t, long theta)
+{
+ long shift, fac;
+
+ if (t = 32*theta)
+ return 0;
+
+ shift = t/theta;
+ fac = theta -
On Mon, 4 June 2007 00:18:21 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
Unchanged:
o error handling
...
Won't happen (unless I get convinced to do otherwise):
o Change LOGFS_BUG() and LOGFS_BUG_ON() to inline functions
These are macros for very much
On Mon, 4 June 2007 00:21:41 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+static DEFINE_MUTEX(compr_mutex);
+
It seems you define a static compre_mutex in both segment.c and in compr.c,
and always lock them both at the same time. Is that a correct observation?
On Sun, 3 June 2007 23:50:55 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+/**
+ * struct logfs_device_ops - device access operations
+ *
+ * @read: read from the device
+ * @write: write to the device
+ * @erase:
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 have naturally
aligned members, so the __packed attribute is
On Sunday 03 June 2007, Jörn Engel wrote:
+/**
+ * struct logfs_device_ops - device access operations
+ *
+ * @read: read from the device
+ * @write: write to the device
+ * @erase: erase part of the device
+ */
+struct
I have a file system that has really odd blocking.
All files have a variable length header (basically a directory
entry) at their start.
Most but not all sectors, have a small fixed length signature as
well as some link data at their start.
The net result is that implimentation
On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote:
On Tuesday 15 May 2007 11:14, Pavel Machek wrote:
Why is this configurable?
The maximum length of a pathname is an arbitrary limit: we don't want to
allocate arbitrary amounts of of kernel memory for pathnames so we introduce
this
On Monday 04 June 2007 12:55, Pavel Machek wrote:
On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote:
On Tuesday 15 May 2007 11:14, Pavel Machek wrote:
Why is this configurable?
The maximum length of a pathname is an arbitrary limit: we don't want to
allocate arbitrary amounts of of
On Mon 2007-06-04 13:25:30, Andreas Gruenbacher wrote:
On Monday 04 June 2007 12:55, Pavel Machek wrote:
On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote:
On Tuesday 15 May 2007 11:14, Pavel Machek wrote:
Why is this configurable?
The maximum length of a pathname is an
On Monday 04 June 2007 13:35, Pavel Machek wrote:
On Mon 2007-06-04 13:25:30, Andreas Gruenbacher wrote:
On Monday 04 June 2007 12:55, Pavel Machek wrote:
On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote:
On Tuesday 15 May 2007 11:14, Pavel Machek wrote:
Why is this
Hi!
You very well know that the vfs has a limit of PATH_MAX characters (4096)
for pathnames. This means that at most that many characters can be passed
at once.
What users can do is something like this:
chdir(some/long/path);
chdir(some/even/longer/path);
...
and the
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
On Sat, Jun 02, 2007 at 02:21:22PM -0400, Trond Myklebust wrote:
Currently, the lease handling is done all in the VFS, and is done prior
to calling any filesystem operations. Bruce's break_lease() inode
operation allows the VFS to notify the filesystem that some operation is
going to be called
On Mon, 4 June 2007 14:38:23 +0100, David Woodhouse wrote:
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];
On Monday 04 June 2007 15:12, Pavel Machek wrote:
How will kernel work with very long paths? I'd suspect some problems,
if path is 1MB long and I attempt to print it in /proc
somewhere.
Pathnames are only used for informational purposes in the kernel, except in
AppArmor of course. /proc only
On Jun 04, 2007 06:20 -0400, David H. Lynch Jr. wrote:
The net result is that implimentation would be simpler if I could
just read/write, the amount of data that can be done with the least
amount of work, even if that is less than was requested.
If I receive a request to read 512 bytes, and
It is not strictly an error to read/write less than the requested amount,
but you will find that a lot of applications don't handle this correctly.
I'd give it a slightly different nuance. It's not an error, and it's a
reasonable thing to do, but there is value in not doing it. POSIX and its
On Mon, Jun 04, 2007 at 09:56:07AM -0700, Bryan Henderson wrote:
Programs that assume a full transfer are fairly common, but are
universally regarded as either broken or just lazy, and when it does cause
a problem, it is far more common to fix the application than the kernel.
Linus has
On Mon, Jun 04, 2007 at 11:02:23AM -0600, Matthew Wilcox wrote:
On Mon, Jun 04, 2007 at 09:56:07AM -0700, Bryan Henderson wrote:
Programs that assume a full transfer are fairly common, but are
universally regarded as either broken or just lazy, and when it does cause
a problem, it is far
Hi,
On Mon, 4 Jun 2007, Theodore Tso wrote:
Hmm, I'm not sure I would go that far. Per the POSIX specification,
we support the optional BSD-style restartable system calls for signals
which will avoid short reads; but this is only true if SA_RESTART is
passed to sigaction(). Without
On Mon, Jun 04, 2007 at 08:57:16PM +0200, Roman Zippel wrote:
On Mon, 4 Jun 2007, Theodore Tso wrote:
Hmm, I'm not sure I would go that far. Per the POSIX specification,
we support the optional BSD-style restartable system calls for signals
which will avoid short reads; but this is only
On Mon, Jun 04, 2007 at 08:57:16PM +0200, Roman Zippel wrote:
That's the last discussion about signals and I/O I can remember:
http://www.ussg.iu.edu/hypermail/linux/kernel/0208.0/0188.html
Well, I think Linus was saying that we have to do both (where the
signal interrupts and where it
On Tuesday 15 May 2007 11:20, Pavel Machek wrote:
Hi!
Pathname matching, transition table loading, profile loading and
manipulation.
So we get small interpretter of state machines, and reason we need is
is 'apparmor is misdesigned and works with paths when it should have
worked with
28 matches
Mail list logo
