On Wednesday February 6, [EMAIL PROTECTED] wrote:
+ dotdot.d_name.name = ..;
+ dotdot.d_name.len = 2;
+
+ lock_kernel();
+ if (!udf_find_entry(child-d_inode, dotdot, fibh, cfi))
+ goto out_unlock;
Have you ever tried this? I think this could never work. UDF doesn't
On Thursday January 17, [EMAIL PROTECTED] wrote:
On Jan 17 2008 00:43, Karel Zak wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers and we don't know what they do.
So, let's use /proc/mounts_v2 ;-)
Was not it like don't use /proc
Hi David,
On Friday November 30, [EMAIL PROTECTED] wrote:
I came across this because I've been making changes to XFS to avoid the
inode hash, and I've found that I need to remove the inode from the
dirty list when setting I_WILL_FREE to avoid this race. I can't see
how this race is
On Friday November 30, [EMAIL PROTECTED] wrote:
On Fri, Nov 30, 2007 at 09:07:06AM +1100, Neil Brown wrote:
Hi David,
On Friday November 30, [EMAIL PROTECTED] wrote:
I came across this because I've been making changes to XFS to avoid the
inode hash, and I've found that I
On Thursday November 8, [EMAIL PROTECTED] wrote:
Not really a credible difference as the reported difference is between
two *clients* and the speed of getattr vs lookup would depend on the
*server*.
Sorry, my bad. I misread your original problem description. It would
appear to be a server
On Tuesday November 6, [EMAIL PROTECTED] wrote:
On Tue, 6 Nov 2007 14:28:11 +0300 Al Boldi [EMAIL PROTECTED] wrote:
Al Boldi wrote:
There is a massive (3-18x) slowdown when re-querying a large nfs dir (2k+
entries) using a simple ls -l.
On 2.6.23 client and server running userland
On Tuesday October 30, [EMAIL PROTECTED] wrote:
Of course snapshot cow elements may be part of more generic element
trees. In general there may be more than one consumer of block usage
hints in a given filesystem's element tree, and their locations in that
tree are not predictable. This
On Thursday October 25, [EMAIL PROTECTED] wrote:
On Mon, 22 Oct 2007, Pekka Enberg wrote:
On 10/22/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Only ramdisk and shmem have been returning AOP_WRITEPAGE_ACTIVATE.
Both of those set BDI_CAP_NO_WRITEBACK. ramdisk never returned it
if
On Friday September 14, [EMAIL PROTECTED] wrote:
This patchset is a medium scale rewrite of the export operations
interface. The goal is to make the interface less complex, and
easier to understand from the filesystem side, aswell as preparing
generic support for exporting of 64bit inode
On Monday August 27, [EMAIL PROTECTED] wrote:
* a bug (AFAICT) in md.c - we open raid components r/w and if it
fails, it fails. Good for our purposes, but... how about raid0 on read-only
devices? In any case, we have a ready place to store mode_t, so it's not a
problem for getting the
It just occurred to me:
If i_version is 64bit, then knfsd would need to be careful when
reading it on a 32bit host. What are the locking rules?
Presumably it is only updated under i_mutex protection, but having to
get i_mutex to read it would seem a little heavy handed.
Should it use a
On Friday July 6, [EMAIL PROTECTED] wrote:
Hi,
On Fri, Jul 06, 2007 at 05:57:49PM +0200, Jörn Engel wrote:
...
Interesting idea. Is it possible to attach several address spaces to an
inode? That would cure some headaches.
GFS2 already uses something like this, in fact by having a
On Tuesday July 3, [EMAIL PROTECTED] wrote:
Getting a snapshot that is useful with respect to application data
requires help from the application.
Certainly.
The app needs to be shutdown or
paused prior to the snapshot and then started up again after
On Tuesday June 26, [EMAIL PROTECTED] wrote:
Posting it here seems the best thing to do.
To the inventor goes naming privilege and I'm calling this one softer raid.
It is a form of storage raid implemented in software, as contrasted to
software and hardware raid which are dependent on using
On Tuesday June 26, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
Sounds a lot like RAIF - ask google for details.
I did not know about RAIF. RAIF merges separate filesystems? That is a
good idea in itself.
My idea is for driver that provides a filesystem from image files it
controls
On Tuesday June 26, [EMAIL PROTECTED] wrote:
Thanks for the brief howto there. I'll install the mdadm suite and
experiment. It seems like a userspace driver?
mdadm is a userspace tool for managing the 'md' driver which is in the
linux kernel.
I don't know what you mean by '2'.
2 meant
On Sunday June 24, [EMAIL PROTECTED] wrote:
+#define PG_blocks20 /* Page has block mappings */
+
I've only had a very quick look, but this line looks *very* wrong.
You should be using PG_private.
There should never be any confusion about whether -private has
buffers or
On Friday June 22, [EMAIL PROTECTED] wrote:
Yes. Your use case is different than mine.
My use case is being able to protect data reliably. Yours?
Saying protect data is nearly meaningless without a threat model.
I bet you don't try to protect data from a direct nuclear hit, or a
court
On Friday June 1, [EMAIL PROTECTED] wrote:
On Thu, May 31, 2007 at 02:31:21PM -0400, Phillip Susi wrote:
David Chinner wrote:
That sounds like a good idea - we can leave the existing
WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
behaviour that only guarantees
On Wednesday May 30, [EMAIL PROTECTED] wrote:
On Fri, May 25, 2007 at 06:25:31PM +0200, Jean noel Cordenner wrote:
The aim is to fulfill a NFSv4 requirement for rfc3530:
5.5. Mandatory Attributes - Definitions
Name# DataType Access Description
On Tuesday May 29, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
md/dm modules could keep count of requests as has been suggested
(though that would be a fairly big change for raid0 as it currently
doesn't know when a request completes - bi_endio goes directly to the
filesystem
On Monday May 28, [EMAIL PROTECTED] wrote:
There are two things I'm not sure you covered.
First, disks which don't support flush but do have a cache dirty
status bit you can poll at times like shutdown. If there are no drivers
which support these, it can be ignored.
There are really
On Monday May 28, [EMAIL PROTECTED] wrote:
On Mon, May 28, 2007 at 12:57:53PM +1000, Neil Brown wrote:
What exactly do you want to know, and why do you care?
If someone explicitly mounts -o barrier and the underlying device
cannot do it, then we want to issue a warning or reject the
mount
On Monday May 28, [EMAIL PROTECTED] wrote:
Neil Brown writes:
[...]
Thus the general sequence might be:
a/ issue all preceding writes.
b/ issue the commit write with BIO_RW_BARRIER
c/ wait for the commit to complete.
If it was successful - done
Thanks everyone for your input. There was some very valuable
observations in the various emails.
I will try to pull most of it together and bring out what seem to be
the important points.
1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.
This is certainly a very attractive
On Friday May 25, [EMAIL PROTECTED] wrote:
2007/5/25, Neil Brown [EMAIL PROTECTED]:
- Are there other bit that we could handle better?
BIO_RW_FAILFAST? BIO_RW_SYNC? What exactly do they mean?
BIO_RW_FAILFAST: means low-level driver shouldn't do much (or no)
error recovery. Mainly
On Monday May 28, [EMAIL PROTECTED] wrote:
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
Thanks everyone for your input. There was some very valuable
observations in the various emails.
I will try to pull most of it together and bring out what seem to be
the important
This mail is about an issue that has been of concern to me for quite a
while and I think it is (well past) time to air it more widely and try
to come to a resolution.
This issue is how write barriers (the block-device kind, not the
memory-barrier kind) should be handled by the various layers.
On Thursday May 17, [EMAIL PROTECTED] wrote:
XOR it (0^0=1), and hence fills up the host disk.
Uhmm... you need to check your maths.
$ perl -e 'printf %d\n, 0^0;'
0
:-)
NeilBrown
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL
in KB).
chunk itself will not overflow (without triggering a BUG).
So change 'chunk' to be 'sector_t, and get rid of the 'BUG' as it becomes
impossible to hit.
Cc: Jeff Zheng [EMAIL PROTECTED]
Signed-off-by: Neil Brown [EMAIL PROTECTED]
### Diffstat output
./drivers/md/raid0.c |3 +--
1
On Wednesday May 16, [EMAIL PROTECTED] wrote:
Any ideas what are the minimum export operation(s) that cifs would need to
add to export under nfsd? It was not clear to me after reading the
Exporting document in Documentation directory.
You need to be able to map a dentry to a filehandle (you
? It is the only thing that I can find
that could conceivably go wrong.
Thanks,
NeilBrown
Signed-off-by: Neil Brown [EMAIL PROTECTED]
### Diffstat output
./drivers/md/raid0.c |1 +
1 file changed, 1 insertion(+)
diff .prev/drivers/md/raid0.c ./drivers/md/raid0.c
--- .prev/drivers/md/raid0.c2007-05
On Thursday May 17, [EMAIL PROTECTED] wrote:
The only difference of any significance between the working
and non-working configurations is that in the non-working,
the component devices are larger than 2Gig, and hence have
sector offsets greater than 32 bits.
Do u mean 2T here?,
On Wednesday May 16, [EMAIL PROTECTED] wrote:
If CIFS provides some fix-length identifier for files, then
you might be able to do it
Most CIFS servers (Windows on NTFS, Samba etc.) can return a unique
identifier (a 64 bit inode number), in conjunction with the volume id,
that is
On Thursday May 17, [EMAIL PROTECTED] wrote:
I tried the patch, same problem show up, but no bug_on report
Is there any other things I can do?
What is the nature of the corruption? Is it data in a file that is
wrong when you read it back, or does the filesystem metadata get
corrupted?
Can
On Wednesday May 16, [EMAIL PROTECTED] wrote:
On Thu, 17 May 2007, Neil Brown wrote:
On Thursday May 17, [EMAIL PROTECTED] wrote:
The only difference of any significance between the working
and non-working configurations is that in the non-working,
the component devices are larger
is used.
So I'm quite certain this bug will cause exactly the problems
experienced!!
Jeff, can you try this patch?
Don't bother about the other tests I mentioned, just try this one.
Thanks.
NeilBrown
Signed-off-by: Neil Brown [EMAIL PROTECTED]
### Diffstat output
./drivers/md/raid0.c
On Wednesday May 16, [EMAIL PROTECTED] wrote:
Anybody have a clue?
No...
When a raid0 array is assemble, quite a lot of message get printed
about number of zones and hash_spacing etc. Can you collect and post
those. Both for the failing case (2*5.5T) and the working case
(4*2.55T) is
On Sunday May 13, [EMAIL PROTECTED] wrote:
On Mon, May 07, 2007 at 08:51:00AM +0100, Christoph Hellwig wrote:
On Mon, May 07, 2007 at 10:06:10AM +1000, Neil Brown wrote:
On Monday May 7, [EMAIL PROTECTED] wrote:
Would you be able to respin that second patch series with one of those
On Friday May 4, [EMAIL PROTECTED] wrote:
On Tuesday May 1, [EMAIL PROTECTED] wrote:
- the calling conversion on the decode side where we first call
-decode_fh to split the filehandle into two blobs only to
recurse back into exportfs and then recurse back into the filesystem
On Monday May 7, [EMAIL PROTECTED] wrote:
Would you be able to respin that second patch series with one of those
changes?
Of course it is actually the first series of patches that introduces
this problem. So maybe just a full respin??
Thanks,
NeilBrown
-
To unsubscribe from this list: send
On Sunday May 6, [EMAIL PROTECTED] wrote:
use vfs_path_lookup instead of open-coding the necessary functionality.
Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED]
Acked-by: NeilBrown [EMAIL PROTECTED]
Thanks,
NeilBrown
---
fs/nfsctl.c | 16 ++--
1 files changed, 6
On Tuesday May 1, [EMAIL PROTECTED] wrote:
On Fri, Mar 30, 2007 at 01:34:53PM +1000, Neil Brown wrote:
On Saturday March 17, [EMAIL PROTECTED] wrote:
less that 2 weeks later
more than one month later :)
Thanks for your explanations.
- the calling conversion on the decode
On Tuesday April 24, [EMAIL PROTECTED] wrote:
If prepare_write fails with AOP_TRUNCATED_PAGE, or if commit_write fails, then
we may have failed the write operation despite prepare_write having
instantiated blocks past i_size. Fix this, and consolidate the trimming into
one place.
..
@@
On Tuesday April 24, [EMAIL PROTECTED] wrote:
+ write_begin: This is intended as a replacement for prepare_write. Called
+by the generic buffered write code to ask the filesystem to prepare
+to write len bytes at the given offset in the file. flags is a field
+for
On Tuesday April 24, [EMAIL PROTECTED] wrote:
BTW. AOP_FLAG_UNINTERRUPTIBLE can be used by filesystems to avoid
an initial read or other sequence they might be using to handle the
case of a short write. ecryptfs uses it, others can too.
For buffered writes, this doesn't get passed in
On Tuesday April 24, [EMAIL PROTECTED] wrote:
On Tue, Apr 24, 2007 at 12:11:19PM +0100, Christoph Hellwig wrote:
On Tue, Apr 24, 2007 at 01:05:49PM +0200, Nick Piggin wrote:
On Tue, Apr 24, 2007 at 11:46:47AM +0100, Christoph Hellwig wrote:
+ page = __grab_cache_page(mapping,
On Friday February 23, [EMAIL PROTECTED] wrote:
On Fri, Feb 23, 2007 at 05:37:23PM -0700, Andreas Dilger wrote:
Probably the only sane thing to do is to remember the bad sectors and
avoid attempting reading them; that would mean marking automatic
versus explicitly requested requests to
On Wednesday February 21, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote on 2007-02-21 00:04:40:
You will need patch f988443a84528bd30c2f474efa5e2c511959f19b [1]
or run
mount -t nfsd nfsd /proc/fs/nfs/nfsd
before starting mountd.
I applied the patch, and attempted the mount
On Tuesday February 20, [EMAIL PROTECTED] wrote:
Hi,
I'm trying to get an nfs server setup on our embedded 2.6.19 kernel
system. I've chosen to use the kernel nfsd module,
and am using the latest nfs-utils.
It all starts running, but I get this:
mount -t nfs 127.0.0.1:/etc /tmp/try
On Tuesday February 6, [EMAIL PROTECTED] wrote:
On Mon, Feb 05, 2007 at 07:20:35PM -0800, Andreas Gruenbacher wrote:
It's actually not hard to fix, and nfsd would look a little less weird.
But
what would this add, what do pathnames mean in the context of nfsd, and
would
nfsd
On Tuesday February 6, [EMAIL PROTECTED] wrote:
On Tue, Feb 06, 2007 at 12:51:52AM -0800, Trond Myklebust wrote:
Who cares? There is no way to export a partial directory, and in any
case the subtree_check crap is borken beyond repair (see cross-directory
renames which lead to actual changes
On Friday February 2, [EMAIL PROTECTED] wrote:
Hello,
here is a bugfix to d_path. Please apply (after 2.6.20).
Looks good! Just a couple of little comments (to prove that I have
really read it and thought about it :-)
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
Reviewed-by:
On Wednesday November 29, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
"hlfsd" stands for Home Link File System Daemon, and a google search
on hlfsd finds it quite nicely.
---
So we would configure /tmp to be type of NFS server served
by hlfsd which would point to som
54 matches
Mail list logo
