Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
Date:Thu, 4 Jul 2019 22:25:11 +0200 From:Rhialto Message-ID: <20190704202511.gd11...@falu.nl> | What is "fslevel 5"? fslevel(8) only explains up to level 4. In fact it | even claims "Note that FFSv2 file systems are always level 4." The level is a constructed value which is essentially meaningless. Currently "level 5" is FFSv2 - and levels 1..4 are all FFSv1 with different variations from the original 1980 version. (ie: the manual ought to be updated...) But if more variations are added to FFSv1 then it will get more levels (1..5 after the next alteration) and FFSv2 will become level 6... This level is puerly an artifact of dumpfs and how it interprets the internal filesystem version/capability indicators - most likely, until we start making variations on FFSv2 formats, printing the level at all for FFSv2 is probably a mistake, right now, FFSv2 simply is FFSv2, whereas FFSv1 has altered over time. (The "level" is printed for FFSv2 and arbitrarily given a value 1 more than the biggest needed for FFSv1, simply to make the same printf statement work for both variants). kre
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
Date:Wed, 3 Jul 2019 21:26:35 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | FFSv1 also has a 32bit (or rather 31bit) limit. Since it counts fragments, | not physical disk blocks, the effective limit for the filesystem size | varies between 1TB (512byte fragments) and 128TB (64kByte fragments). The other significant difference is that FFSv1 uses 32 bit time_t's (for everything) with microsecond precision, FFSv2 uses 64 bit time_t's with nanosecond prevision. This means that in 2038 (unless we do a fiddle, which we will almost certainly do) FFSv1 filesystems will all become useless. But, as no-one has FFS filesystems with (legitimate) dates in them before 1970 we can easily change the range of 32 bit time_t values in the filesystem from 1902-2038 to instead be 1970-2106 by simply treating the timestamp recorded in the filesystem as an unsigned value (when converting it to the 32 bit time_t that is used internally). A bigger problem is continuing to support the old APIs with 32 bit time_t's in compat mode .. we should really be starting now to make sure that no-one has anything left that uses 32 bit time_t's well before 2038. We could move the range for those as well (with libc hacks) making it be something like 1950-2086 (approx - or something like that) but that can be dangerous to apps that beliee they understand the time_t representation and don't simply treat it as an opaque value to hand off to localtime(). An insignificant difference is that FFSv2 has the totally useless birthtime timestamp added (which ought to be removed again...) kre
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
Date:Wed, 3 Jul 2019 19:43:20 +0200 From:tlaro...@polynum.com Message-ID: <20190703174320.ga7...@polynum.com> | But if somebody had numbers about tests comparing FFSv1 and FFSv2 and | the efficiency (for formatting, FFSv1 pre-allocates (ie: zeroes) all of the inode blocks that will ever be inode blocks. FFSv2 doesn't, it keeps track of which inode blocks have been initialised, and clears new ones when they're actually needed (if one is needed, it will be being written to, to store some new inode data, so aside from the cost of zeroing a block of mem, this is more or less free - atually cheaper than FFSv1 as there is no need or point in reading the existing inode block ... but it doesn't happen often so the operational difference is negligible). Since an empty FFS filesystem is essentially just super block and backups, cylinder group headers, and inode blocks, not init'ing the inode blocks (which are the vast majority of what a FFSv1 init needs to write) saves lots of newfs time. kre
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
mueller6...@twc.com ("Thomas Mueller") writes: >I looked using ls -la / and ls -la //root and found >no .attribute subdirectory. I ran dumpfs to verify whether the file system >was UFS1 or UFS2. Have a look at the exattrctl command. It's used to create the attribute storage. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
from Greg Troxel: > Saying that "UFS2" does or does not have support does not make senes, > without saying "UFS2 in FooBSD". As I understand it, in NetBSD, UFS1 > has support and UFS2 doesn't. FreeBSD may well be different. Since > we have a long tradition of moving code back and forth, perhaps > someone should have a look? UFS or ffs implementations have differences, which may be the reason why Linux support is read-only and there is no support in Haiku. I found, a few years back, that FreeBSD and NetBSD could not mount a DragonFly BSD partition, and DragonFly BSD (using downloaded image written to USB stick) couldn't mount a NetBSD or FreeBSD partition. Last time I downloaded a DragonFly image to write to USB stick, it hung on boot. from Michael van Elst: > mueller6...@twc.com ("Thomas Mueller") writes: > >I remember reading on Haiku web site (haiku-os.org), with reference to > >cross-compiling, that UFS2 supports extended attributes. I also checked > >Wikipedia (Unix File System), and UFS2 supports extended attributes. > Yes, but we haven't implemented that part. > >Would UFS1 level 4 also support extended attributes? > Originally no, but it was added to UFS1. The extended attributes are > stored in subdirectory ".attribute" of the mountpoint, so the > on-disk structure isn't really changed. I looked using ls -la / and ls -la //root and found no .attribute subdirectory. I ran dumpfs to verify whether the file system was UFS1 or UFS2. Subject did not appear on my last post because of either a mouse copy-and-paste error or accidentally deleting S in Subject from the keyboard. Header line appeared as ubject: Re: FFSv1 (UFS1) vs FFSv2 (UFS2) I also corrected my email address, looked for and fixed other occurrences of "mueller6726". Tom
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
On Wed 03 Jul 2019 at 12:21:39 -0400, Greg Troxel wrote: > newfs(8) and fsck_ffs(8) explain this, although I can see that it's > slightly hard to follow. Basically, retrocomputing aside, there is > > - UFS1 level 4, which has a "FFSv2-format superblock" > - UFS2 What is "fslevel 5"? fslevel(8) only explains up to level 4. In fact it even claims "Note that FFSv2 file systems are always level 4." But I have # dumpfs /dev/rdk8 file system: /dev/rdk8 format FFSv2 endian little-endian location 65536 (-b 128) magic 19540119timeThu Jul 4 06:15:26 2019 superblock location 65536 id [ x ] cylgrp dynamic inodes FFSv2 sblock FFSv2 fslevel 5 -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: none
"Thomas Mueller" writes: > I remember reading on Haiku web site (haiku-os.org), with reference to > cross-compiling, that UFS2 supports extended attributes. I also > checked Wikipedia (Unix File System), and UFS2 supports extended > attributes. Saying that "UFS2" does or does not have support does not make senes, without saying "UFS2 in FooBSD". As I understand it, in NetBSD, UFS1 has support and UFS2 doesn't. FreeBSD may well be different. Since we have a long tradition of moving code back and forth, perhaps someone should have a look?
[no subject]
from Michael van Elst: > tlaro...@polynum.com writes: > >I guess that my uncertainty about FFSv1 vs FFSv2 comes partly from this > >confusion between fdisk(8) vs gpt(8) and the 32bits limit and the > >mention of > 1To in newfs(8) man page. > FFSv1 also has a 32bit (or rather 31bit) limit. Since it counts fragments, > not physical disk blocks, the effective limit for the filesystem size > varies between 1TB (512byte fragments) and 128TB (64kByte fragments). I believe high-capacity external hard drives, mainly USB 3 but also eSATA, have sector size 4 KB and do not attempt to make it look like 512 bytes. That is the case with Micronet Fantom GForce external hard drives that have connectorss for both eSATA and USB 3. Then could UFS1 handle uo to 8 TB? I still tend to use UFS2, which is FreeBSD's default. Excerpt from Greg Troxel: - UFS1 level 4, which has a "FFSv2-format superblock" - UFS2 > There are statements about UFS2 being better for multi-TB filesystems, > but as far as I know UFS1 works fine. > Another issue is that we have support for extended attributes in UFS1, > but not UFS2 (I believe for no good reason, just that it was added in > one place and not the other, but I'm not sure). This is necessary for > serving glusterfs. I remember reading on Haiku web site (haiku-os.org), with reference to cross-compiling, that UFS2 supports extended attributes. I also checked Wikipedia (Unix File System), and UFS2 supports extended attributes. Would UFS1 level 4 also support extended attributes? Haiku uses extended attributes, and I've been trying to cross-compile Haiku from FreeBSD and NetBSD, but no success so far. Tom
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
Hello, On Wed, Jul 03, 2019 at 09:26:35PM -, Michael van Elst wrote: > tlaro...@polynum.com writes: > > >I guess that my uncertainty about FFSv1 vs FFSv2 comes partly from this > >confusion between fdisk(8) vs gpt(8) and the 32bits limit and the > >mention of > 1To in newfs(8) man page. > > FFSv1 also has a 32bit (or rather 31bit) limit. Since it counts fragments, > not physical disk blocks, the effective limit for the filesystem size > varies between 1TB (512byte fragments) and 128TB (64kByte fragments). That's an important information! This also means that, using the default values, FFSv1 can handle 8TB (block size 32KB, and fragment size 4KB are the defaults for disk size >= 128 GB). Thank you! -- Thierry Laronde http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C