From: Nicolas George <nicolas.george@ens.fr>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Filesystem for mobile hard drive
Date: Mon, 13 Feb 2006 11:35:12 +0100 [thread overview]
Message-ID: <20060213103512.GA5157@clipper.ens.fr> (raw)
In-Reply-To: <43EFEE57.7070009@cfl.rr.com>
[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]
Le quartidi 24 pluviôse, an CCXIV, Phillip Susi a écrit :
> Ahh yes, the per file limit. BTW, why are you saying "To" and "Go" when
> you apparently mean "TB" and "GB"?
I use the french word octet instead of byte, because it is less error prone
(when you read "mb", does-it really mean megabit, or does it mean that the
author is lazy about capitalization?) and a little bit more precise. Tough I
actually am French, I did not start using a French word in English by
myself. I copy a practice of the IETF: the RFCs use octet more than byte.
> The fat data structures do not encourage fragmentation any more or less
> than ext2/3. NTFS is slightly better, more comparable to reiserfs than
> ext2/3, but the difference is small. What causes massive fragmentation
> is how the driver chooses to allocate new blocks as you write to files.
> Microsoft has always used about the worst possible algorithm for doing
> this you can imagine, which is why fragmentation has always been a big
> problem on their OSes. Linux is smarter and allocates blocks such that
> fragmentation is kept to a minimum.
I believe you about that.
> I have not done any testing, but I know no reason why it would be worse
> than fat.
That is a very good point. If windows can read UDF on hard drives and not
only DVD, UDF could probably supersede FAT completely.
Thank you for pointing me that direction.
> It does not do transaction logging, and there currently is no
> fsck for it, so for safety reasons, it may not be such a good choice.
I have a Solaris 9 near at hand, and I see a /lib/fs/udfs/fsck, and in the
source tarball of OpenSolaris, I find a directory
usr/src/cmd/fs.d/udfs/fsck/. It does not compile out of the box, but it may
be possible to port it with limited effort.
> I agree. I think the VFS layer should process the uid/gid options. By
> default it should replace nobody with the specified id, and fat and ntfs
> should just report all files as owned by nobody. Then a new option
> should be added to force the translation for all ids, not just nobody.
I agree with that (except maybe for the NTFS part, which I do not know; let
us just say "UID-less filesystems"). Maybe a full UID translation system
similar th the one in NFS could be useful, or a generic hook for modules,
but having basic UID overriding would be great.
Unfortunately, the VFS subsystem is something too complex for me at this
time.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 185 bytes --]
next prev parent reply other threads:[~2006-02-13 10:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-12 15:03 Filesystem for mobile hard drive Nicolas George
2006-02-13 0:46 ` Phillip Susi
2006-02-13 1:07 ` Nicolas George
2006-02-13 2:26 ` Phillip Susi
2006-02-13 8:59 ` Jan Engelhardt
2006-02-13 9:23 ` Kalin KOZHUHAROV
2006-02-13 16:07 ` Phillip Susi
2006-02-13 10:35 ` Nicolas George [this message]
2006-02-13 15:56 ` Phillip Susi
2006-02-13 17:18 ` Nicolas George
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=20060213103512.GA5157@clipper.ens.fr \
--to=nicolas.george@ens.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=psusi@cfl.rr.com \
/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