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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.