headers
Bryan Henderson | 2 Jun 2003 18:13
Picon
Favicon

Re: nfs exporting my stacked fs


>Then server admins are deliberately putting themselves in a situation
>where their users may see data corruption. The above problem is
>trivially solved by means of the 'fsid' export option.

Agreed, but note that you're talking specifically about a very recent Linux
system with a careful system administrator.  I was talking about the world
of NFS in general -- the practical world.

>For most setups, this should not be necessary (since device numbers
>will suffice).  Those that don't have permanently allocated device
>numbers (e.g. fibre channel), should use the fsid export option in
>order to provide a permanent value...

But now you're talking about sufficiency, whereas I was talking about
actually implementing unique fsids.  Device number is clearly sufficient,
since people have been using it for decades.  But it does not come close to
being a real fsid.  No device numbers in Linux (on architectures I know
about) are permanently associated with physical devices.  Lots of things,
including recabling, can change them.  Moreover, filesystems are not
permanently associated with physical devices.  You can move a filesystem
from one device to another.

The fsid export option, while a leap ahead of what we had before, is
clearly not the ultimate solution to the fsid problem, because it requires
too much human participation.  System administrators don't normally have to
administrate at that level.  It's like choosing device addresses and IRQ
levels when you install network cards.

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Chow | 5 Jun 2003 17:38

Re: nfs exporting my stacked fs


>Agreed, but note that you're talking specifically about a very recent Linux
>system with a careful system administrator.  I was talking about the world
>of NFS in general -- the practical world.
>
>  
>
>>For most setups, this should not be necessary (since device numbers
>>will suffice).  Those that don't have permanently allocated device
>>numbers (e.g. fibre channel), should use the fsid export option in
>>order to provide a permanent value...
>>    
>>
OK, I think I'd ask Trond a similar question long ago about fsids. One 
good example of the need of fsid
is high availability NFS . When a shared volume over fibre-channel, SAN 
or shared SCSI will definitely alter the device numbers without having 
to recabling . IBM's SAN unit does support virtual LUNs (I had a go with 
FastT 200 and Bryan should know better than me do) which device number 
has no sense at all. One or more machines can share the same physical 
volume with different LUNs (seen by the OS) and of course, device 
numbers are just junk. I think SAN is a subsystem designed for server 
farms, it is a bit difficult to make cluster of servers to maintain 
universal global device numbers, otherwise failover doesn't work though. 
May be for apps but unfortunately not NFS without fsid .

>But now you're talking about sufficiency, whereas I was talking about
>actually implementing unique fsids.  Device number is clearly sufficient,
>since people have been using it for decades.  But it does not come close to
>being a real fsid.  No device numbers in Linux (on architectures I know
(Continue reading)

Permalink | Reply | 501 comments |
headers
Bryan Henderson | 5 Jun 2003 18:30
Picon
Favicon

Re: nfs exporting my stacked fs


>>The fsid export option, while a leap ahead of what we had before, is
>>clearly not the ultimate solution to the fsid problem, because it
requires
>>too much human participation.  System administrators don't normally have
to
>>administrate at that level.  It's like choosing device addresses and IRQ
>>levels when you install network cards.
>>
>>
>Why not? We did that in the old days didn't we?

Because it isn't the old days.  I agree that in the old days, having the
system administrator manually manage export IDs would be perfectly
reasonable, as was having the system administrator manage IRQs and device
addresses.  But today, people generally expect more automation from
computers.

>I strongly support the fsid option as there is
>no point to remove it. For other users (admin who don't care or
>standalone nfs servers), nfsd can still use the device numbers to
>generate file handles.

Me too.  In fact, I'm not aware of any dissent on this point.  As I
mentioned much earlier, the "fsid" option is better than even a true fsid
in some cases.  With it, you can distinguish between two exports of a
single filesystem.

But we should all bear in mind that an fsid problem continues to exist.
Non-Linux systems don't have an export option to set the fsid.  Old Linux
(Continue reading)

Permalink | Reply | 501 comments |
headers
Will Dyson | 8 Jun 2003 03:34
Picon
Favicon

i_op->listxattr semantics

Hello all,

I am attempting to implement support for extended attributes in the Be
Filesystem (befs) driver. But I am stuck trying to figure out why the
getfattr program does not list my attributes.

Below is a test version of befs_listxattr that gives all files one
attribute named "MyAttr". When I mount my filesystem on /befs (in
2.5.69-uml) and issue the command "getfattr -d /befs", no attributes are
printed. The debugging statements appear in my syslog, so I know the
function is being called.

Can anyone help me figure out what I am doing wrong? Thanks!

static ssize_t
befs_listxattr(struct dentry *dentry, char *buffer, size_t size)
{
	struct super_block *sb = dentry->d_inode->i_sb;
	ssize_t attr_len = 0;
	char *attr = "MyAttr";

	befs_debug(sb, "---> befs_listxattr for inode %lu "
			"with %d buffer_size",
			dentry->d_inode->i_ino, size);

	attr_len = strlen(attr);
	
	if (buffer) {
		memcpy(buffer, attr, attr_len);
		buffer[attr_len] = '\0';
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nathan Scott | 8 Jun 2003 04:07
Picon
Favicon

Re: i_op->listxattr semantics

On Sat, Jun 07, 2003 at 09:34:34PM -0400, Will Dyson wrote:
> Hello all,
> 
> I am attempting to implement support for extended attributes in the Be
> Filesystem (befs) driver. But I am stuck trying to figure out why the
> getfattr program does not list my attributes.
> 
> Below is a test version of befs_listxattr that gives all files one
> attribute named "MyAttr". When I mount my filesystem on /befs (in
> 2.5.69-uml) and issue the command "getfattr -d /befs", no attributes are
> printed. The debugging statements appear in my syslog, so I know the
> function is being called.
> 
> Can anyone help me figure out what I am doing wrong? Thanks!

At first guess, probably the lack of a namespace prefix is causing
your problem - see attr(5) and listxattr(2).

> static ssize_t
> befs_listxattr(struct dentry *dentry, char *buffer, size_t size)
> {
> 	struct super_block *sb = dentry->d_inode->i_sb;
> 	ssize_t attr_len = 0;
> 	char *attr = "MyAttr";

Try 's/MyAttr/user.MyAttr/g' or whichever namespace is appropriate.

cheers.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Josh Konkol | 9 Jun 2003 16:53

Bad File descriptor

I'm running Suse8.0 with a 10 Gb ext3 root partition.  I'm having problems 
accessing my modem using sendpage.  The reason I'm posting to this group is 
I don't think this is a modem problem, I'm afraid it's a file system 
corruption problem.

Whenever I try to access the modem I get the following error in 
/var/log/messages:

Jun  9 09:40:14 nagios sendpage[5423]: Modem 'sportster': could not start 
Device::Serial port: Bad file descriptor

Can anyone confirm or deny this is a file system problem, or better yet do 
any of you Linux Guru's out there have any suggestions on how to fix this 
problem ?

TIA

Josh

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Bryan Henderson | 10 Jun 2003 19:00
Picon
Favicon

Re: Bad File descriptor


>...I'm afraid it's a file system corruption problem.
>
>Whenever I try to access the modem I get the following error in
>/var/log/messages:
>
>Jun  9 09:40:14 nagios sendpage[5423]: Modem 'sportster': could not start
>Device::Serial port: Bad file descriptor
>
>Can anyone confirm or deny this is a file system problem...

"Bad file descriptor" is unlikely to be a filesystem corruption problem per
se.  It's used for a variety of program errors that are specific to a
particular file descriptor.  E.g. no such file descriptor, file descriptor
is defined for reading and you're trying to write, file descriptor is for
the wrong type of file for the attempted operation.

Sadly, 'sendpage' is being rather terse with its error information --
there's no indication of what file it is trying to use.  Still, if you
could figure out what device special file name it associates with the modem
'Sportster', you could look at it with 'ls' and ensure that it looks like a
serial port device special file and try to use it with some simpler program
such as 'minicom' to isolate the problem.

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Livio Baldini Soares | 13 Jun 2003 05:44
Picon
Picon
Favicon

Race with inodes in I_FREEING state

  Hello! 

  I'm developing a file system for Linux (I'm currently only using the
2.4 tree), and  have seem to have  hit a small race with  the VFS code
starting to iget()  an inode while it's being  freed, which is causing
my code to panic.

  The race occurs in the following scenario:

1) prune_icache() is called, and inode $x$ (ino = $z$) is removed from
   the inode hash.

2) dispose_list() is called, but is preempted/scheduled.

3) Another task  calls iget() for inode $y$ (ino  also = $z$), doesn't
   find it in the hash, and reads the inode (read_inode()). 

4) dispose_list() wakes up, and finally calls FS-specific clear_inode()
   operation on inode $x$.

  It _is_ true that $x$ on steps 1 and 4 is a different inode than $y$
in step 3. However, my FS  has some hashed/shared data, kept in 'union
u', which is  deleted when clear_inode() is called. So,  in the end of
step 4, inode $y$ has a broken 'u' field, pointing to deleted memory.

  After looking around in the  archive, I believe this race is similar
to the one described here, by Niel Brown:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105235852013658&w=2

  Does this not also happen in  version 2.4.20? Can anybody tell me if
(Continue reading)

Permalink | Reply | 3 comments |
headers
Neil Brown | 13 Jun 2003 07:02
X-Face
Picon
Picon
Favicon

Re: Race with inodes in I_FREEING state

On Friday June 13, livio <at> ime.usp.br wrote:
>   Hello! 
> 
>   I'm developing a file system for Linux (I'm currently only using the
> 2.4 tree), and  have seem to have  hit a small race with  the VFS code
> starting to iget()  an inode while it's being  freed, which is causing
> my code to panic.
> 
>   The race occurs in the following scenario:
> 
> 1) prune_icache() is called, and inode $x$ (ino = $z$) is removed from
>    the inode hash.
> 
> 2) dispose_list() is called, but is preempted/scheduled.
> 
> 3) Another task  calls iget() for inode $y$ (ino  also = $z$), doesn't
>    find it in the hash, and reads the inode (read_inode()). 
> 
> 4) dispose_list() wakes up, and finally calls FS-specific clear_inode()
>    operation on inode $x$.
> 
>   It _is_ true that $x$ on steps 1 and 4 is a different inode than $y$
> in step 3. However, my FS  has some hashed/shared data, kept in 'union
> u', which is  deleted when clear_inode() is called. So,  in the end of
> step 4, inode $y$ has a broken 'u' field, pointing to deleted memory.
> 
>   After looking around in the  archive, I believe this race is similar
> to the one described here, by Niel Brown:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=105235852013658&w=2
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andreas Dilger | 13 Jun 2003 09:35

Re: Race with inodes in I_FREEING state

On Jun 13, 2003  15:02 +1000, Neil Brown wrote:
> >   I'm developing a file system for Linux (I'm currently only using the
> > 2.4 tree), and  have seem to have  hit a small race with  the VFS code
> > starting to iget()  an inode while it's being  freed, which is causing
> > my code to panic.
> > 
> >   The race occurs in the following scenario:
> > 
> > 1) prune_icache() is called, and inode $x$ (ino = $z$) is removed from
> >    the inode hash.
> > 
> > 2) dispose_list() is called, but is preempted/scheduled.
> > 
> > 3) Another task  calls iget() for inode $y$ (ino  also = $z$), doesn't
> >    find it in the hash, and reads the inode (read_inode()). 
> > 
> > 4) dispose_list() wakes up, and finally calls FS-specific clear_inode()
> >    operation on inode $x$.
> > 
> >   It _is_ true that $x$ on steps 1 and 4 is a different inode than $y$
> > in step 3. However, my FS  has some hashed/shared data, kept in 'union
> > u', which is  deleted when clear_inode() is called. So,  in the end of
> > step 4, inode $y$ has a broken 'u' field, pointing to deleted memory.
> > 
> >   After looking around in the  archive, I believe this race is similar
> > to the one described here, by Niel Brown:
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=105235852013658&w=2
> > 
> >   Does this not also happen in  version 2.4.20? Can anybody tell me if
> > my logic is  wrong, or if I'm just plain doing  something stupid in my
(Continue reading)

Permalink | Reply | 1 comment |

Gmane