From: Andreas Dilger <adilger@clusterfs.com>
To: Barry Bouwsma <linuxbugs@dyndns.dk>
Cc: Linux Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: UFS1 filesystem compatibility problem under Linux
Date: Tue, 30 Nov 2004 13:57:22 -0700 [thread overview]
Message-ID: <20041130205722.GD22547@schnapps.adilger.int> (raw)
In-Reply-To: <200411301423.iAUENK601275@Mail.NOSPAM.DynDNS.dK>
[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]
On Nov 30, 2004 15:23 +0100, Barry Bouwsma wrote:
> I've had absolutely no problems under FreeBSD (apart from possibly
> finding one or two bits of code that needed to be fixed) when I've
> made regular use of fragment sizes up to and including the block
> size (as large as 65536 bytes), so long as fsize is within the range
> of bsize/8 to bsize.
>
> Question: Is there a reason that the Linux UFS code would be unable
> to handle frag sizes larger than 4k, or is this simply an arbitrary
Linux requires blocksize <= PAGE_SIZE, so basically all filesystems
use blocksize <= 4096 unless they implement support internally for
reading/writing partial disk blocks from the page or buffer cache.
With ext2/3 it is possible to change the number of inodes allocated
without changing the blocksize (less inodes per block group). If you
care about mounting under Linux it might be worthwhile seeing if UFS
can do the same.
> + (REG) Maximum file size depends on the block size on your
> filesystem. For ext2 (and UFS, SysVFS and similar
> filesystems), the limits are:
> Block size Maximum file size (GiBytes)
> 512 B 2
> 1 kiB 16
> 2 kiB 128
> 4 kiB 1024
> 8 kiB 8192 (PAGE_SIZE must be >= 8 kiB)
This is it exactly.
> Hmmm, this reference to PAGE_SIZE is interesting -- the reason
> I'm asking all these stupid questions is to know whether some
> out-of-the-box on-CD-or-similar Linux could be expected to be
> able to handle my UFS1 filesystem as described above, with no
> need for a custom or tweaked kernel.
It seems unlikely (though not impossible, I haven't checked the UFS
code) than it is possible to mount your filesystem without serious
hacking to the filesystem/VFS/VM, unless of course you are mounting
on an ia64 machine (or similar) with 64kB PAGE_SIZE. Sadly, x86_64
does not support a larger PAGE_SIZE than 4096 (until you get to 4MB
or something like that).
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2004-11-30 21:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-30 14:23 Barry Bouwsma
2004-11-30 20:57 ` Andreas Dilger [this message]
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=20041130205722.GD22547@schnapps.adilger.int \
--to=adilger@clusterfs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxbugs@dyndns.dk \
/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
Powered by JetHome