public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sergey Vlasov <vsu@altlinux.ru>
To: Paul Serice <paul@serice.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] iso9660 Inodes Anywhere and NFS
Date: Wed, 2 Jun 2004 15:44:11 +0400	[thread overview]
Message-ID: <20040602154411.0032d0f5.vsu@altlinux.ru> (raw)
In-Reply-To: <40BD2841.2050509@serice.net>

[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]

On Tue, 01 Jun 2004 20:07:13 -0500 Paul Serice wrote:

> This is my fourth attempt to patch the isofs code.  It is similar to
> the last posting except this one implements the NFS get_parent()
> method which has always been missing.
> 
> The original problem I set out to addresses is that the current
> iso9660 file system cannot reach inodes located beyond the 4GB
> barrier.  This is caused by using the inode number as the byte offset
> of the inode data.  Being 32-bits wide, the inode number is unable to
> reach inode data that does not reside on the first 4GB of the file
> system.
> 
> This causes real problems with "growisofs"
> 
>      http://fy.chalmers.se/~appro/linux/DVD+RW/#isofs4gb
> 
> and my pet project "shunt"
> 
>      http://www.serice.net/shunt/
> 
> This patch switches the isofs code from iget() to iget5_locked() which
> allows extra data to be passed into isofs_read_inode() so that inode
> data anywhere on the disk can be reached.
> 
> The inode number scheme was also changed.  Continuing to use the byte
> offset would have resulted in non-unique inodes in many common
> situations, but because the inode number no longer plays any role in
> reading the meta-data off the disk, I was free to set the inode number
> to some unique characteristic of the file.  I have chosen to use the
> block offset which is also 32-bits wide.
> 
> Lastly, the pre-patch code uses the default export_operations to
> handle accessing the file system through NFS.  The problem with this
> is that the default NFS operations assume that iget() works which is
> no longer the case because of the necessity of switching to
> iget5_locked().  So, I had to implement the NFS operations too.  As a
> bonus, I went ahead and implemented the NFS get_parent() method which
> has always been missing.
> 
> Thanks,
> Paul Serice

> diff -uprN -X dontdiff linux-2.6.7-rc2/fs/isofs/export.c linux-2.6.7-rc2-isofs.3/fs/isofs/export.c
> --- linux-2.6.7-rc2/fs/isofs/export.c	1969-12-31 18:00:00.000000000 -0600
> +++ linux-2.6.7-rc2-isofs.3/fs/isofs/export.c	2004-06-01 15:42:51.000000000 -0500
...
> +/* The .get_parent method should be added, but .get_parent has never
> + * been implemented in the isofs code.  So, its absence will not be
> + * sorely missed. */

Obviously this comment is stale.

> diff -uprN -X dontdiff linux-2.6.7-rc2/fs/isofs/inode.c linux-2.6.7-rc2-isofs.3/fs/isofs/inode.c
> --- linux-2.6.7-rc2/fs/isofs/inode.c	2004-05-31 03:53:07.000000000 -0500
> +++ linux-2.6.7-rc2-isofs.3/fs/isofs/inode.c	2004-06-01 16:39:10.000000000 -0500
> @@ -740,17 +728,14 @@ root_found:
>  	   
>  	/* RDE: data zone now byte offset! */

This comment is now wrong too.

> -	first_data_zone = ((isonum_733 (rootp->extent) +
> -			  isonum_711 (rootp->ext_attr_length))
> -			 << sbi->s_log_zone_size);
> +	first_data_zone = isonum_733 (rootp->extent) +
> +			  isonum_711 (rootp->ext_attr_length);
>  	sbi->s_firstdatazone = first_data_zone;

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-06-02 11:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-02  1:07 [PATCH] iso9660 Inodes Anywhere and NFS Paul Serice
2004-06-02 11:44 ` Sergey Vlasov [this message]
2004-06-02 13:46   ` Paul Serice
2004-06-09  5:24 ` Eric Lammerts
2004-06-09 10:03   ` Paul Serice
2004-06-09 13:11     ` Eric Lammerts
2004-06-10  3:23       ` Paul Serice

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040602154411.0032d0f5.vsu@altlinux.ru \
    --to=vsu@altlinux.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@serice.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox