From: "Adam J. Richter" <adam@yggdrasil.com>
To: kernel@bonin.ca
Cc: aia21@cantab.net, linux-kernel@vger.kernel.org
Subject: Re: Loop devices under NTFS
Date: Tue, 27 Aug 2002 05:40:52 -0700 [thread overview]
Message-ID: <200208271240.FAA04753@adam.yggdrasil.com> (raw)
At 05:48 27/08/02, Andre Bonin wrote:
>"mount -o loop -r -t iso9660 /mnt/win_d/Source/Iso/Red\ Hat\
>7.3/valhalla-i386-disc1.iso /mnt/rh7.3/cd1"
>
>It gives me an error
>"ioctl: LOOP_SET_FD: Invalid argument"
I believe that NTFS does not provide
address_space_operations->{prepare,commit}_write for plain files, so
the version of loop.c in stock 2.5.31 will not work.
I posted an update for loop.c that I posted on August 15th:
( http://marc.theaimsgroup.com/?l=linux-kernel&m=102941520919910&w=2 ).
That update included a hack (originally conceived by Andrew Morton and
originally implemented Jari Ruusu) to use file_operations->{read,write}
for mounting files on file systems that do not provide
{prepare,commit}_write, although this involves an extra data copy if
a transformation (such as encryption) is selected.
I submitted the loop.c update to Linus at least a week ago, but
I have not seen it appear in
ftp://ftp.kernel.org/pub/linux/kernel/people/dwmw2/bk-2.5.
Side note:
There are only a few file systems that provide writable files
without aops->{prepare,commit}_write. I think they are just tmpfs,
ntfs and intermezzo. If all file systems that provided writable files
could be expected to provide {prepare,commit}_write, I could eliminate
the file_ops->{read,write} code from loop.c. I wish I understood if
there really is a need for a file system to be able to provide a
writable random access file (as opposed to /dev/tty) that does not
have aops->{prepare,commit}_write. I would be interesting in knowing
if there is anything preventing implementation of
{prepare,commit}_wriet in ntfs.
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
next reply other threads:[~2002-08-27 12:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-27 12:40 Adam J. Richter [this message]
2002-08-27 12:46 ` Anton Altaparmakov
2002-08-27 13:15 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2002-08-29 11:00 Adam J. Richter
2002-08-29 11:27 ` Anton Altaparmakov
2002-08-29 15:16 ` Jari Ruusu
2002-08-28 9:17 Adam J. Richter
2002-08-28 1:49 Adam J. Richter
2002-08-28 8:36 ` Urban Widmark
2002-08-28 1:06 Adam J. Richter
2002-08-28 15:50 ` Andre Bonin
2002-08-28 16:41 ` Christoph Hellwig
2002-08-27 23:42 Adam J. Richter
2002-08-27 23:59 ` Christoph Hellwig
2002-08-27 13:53 Adam J. Richter
2002-08-27 17:04 ` Christoph Hellwig
2002-08-27 17:26 ` Jan Harkes
2002-08-27 13:23 Adam J. Richter
2002-08-27 13:27 ` Christoph Hellwig
2002-08-27 4:48 Andre Bonin
2002-08-27 9:17 ` Anton Altaparmakov
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=200208271240.FAA04753@adam.yggdrasil.com \
--to=adam@yggdrasil.com \
--cc=aia21@cantab.net \
--cc=kernel@bonin.ca \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®