Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
First, thank you for all the explanations in this thread. They were very clarifying. On lug 05 6:26, Robert Elz wrote: [...] > An insignificant difference is that FFSv2 has the totally useless birthtime > timestamp added (which ought to be removed again...) What do you mean here by "birthtime"? The creation time of each file, or the creation time of the filesystem itself? Rocky
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: 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
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
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). -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
On Thu, Jul 04, 2019 at 12:13:05AM +0700, Gua Chung Lim wrote: > > If the partition is more than 2To, will the FFSv1 be unable to access > > some blocks? > AFAIK, FFS or FFS2 suports pretty big slice (much bigger than 2TB). > The actual limitation is MBR. Maybe you have to use GPT. > Correct me. if I'm wrong. Yes, I use GPT since the MBR is limited to 32bits for #sectors of the partition table. 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. But if somebody had numbers about tests comparing FFSv1 and FFSv2 and the efficiency (for formatting, yes; but one formats only once; more efficient for reading? For writing? More space for data and less for metadata? Etc.)... -- Thierry Laronde http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
> If the partition is more than 2To, will the FFSv1 be unable to access > some blocks? AFAIK, FFS or FFS2 suports pretty big slice (much bigger than 2TB). The actual limitation is MBR. Maybe you have to use GPT. Correct me. if I'm wrong. -- Gua Chung Lim "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." -- Dennis M. Ritchie
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
Hello, On Wed, Jul 03, 2019 at 12:21:39PM -0400, Greg Troxel wrote: > tlaro...@polynum.com writes: > > > I was assuming (don't know why) that when newfs(8)'ing a partition with > > more than 1To, the format would be, automatically FFSv2, FFSv1 being > > the default otherwise. > > 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 > > 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. > > > Dumpfs(8) is a bit confusing since the superblock are said to be FFSv2, > > while the filesystem is identified as FFSv1. So I gather that, having > > not explicitely requested UFS2, it is UFS1 nonetheless. > > Yes. That's what newfs(8) says. > > > The question is: is there any problem to have a more than 1To partition > > with FFSv1? Or is FFSv2 "simply" fastest, specially when using newfs, > > and not trying to be smart with cylinders and grouping? > > The rotational stuff is gone in UFS1 level 4. See fsck_ffs(8) > > > If the partition is more than 2To, will the FFSv1 be unable to access > > some blocks? > > I believe it will be fine. I have not been seeing reports of this, and > I would think that if there were we would have updated the man page and > adeed a warning/check in newfs. > > > But overall, it seems that for 2T and up, the standard approach is: > >use UFS1 if you think you want to serve gluster from it, otherwise >use UFS2 > > I am unclear on any really compelling arguments for UFS2 vs > UFS1/ffsv2-super-block. Thanks for the clarifications. One main difference is the time to format huge partitions. It takes a really long time with UFSv1 while it is fast with UFSv2. In my case, it was beneficial to use (even by chance) UFSv1 since it is obviously writing/reading more blocks and this serves as a diagnostic for the health of the device about which I had worries about (the disk has been replaced so it is not any more serving 24/24, 7/7 data, but I was trying to see if it could serve as a third level back-up with sporadic writes and no reads---it has almost exhausted [as far as SMART is explicit] its spare of sectors, but otherwise seems sound). Thanks again! -- Thierry Laronde http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: FFSv1 (UFS1) vs FFSv2 (UFS2)
tlaro...@polynum.com writes: > I was assuming (don't know why) that when newfs(8)'ing a partition with > more than 1To, the format would be, automatically FFSv2, FFSv1 being > the default otherwise. 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 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. > Dumpfs(8) is a bit confusing since the superblock are said to be FFSv2, > while the filesystem is identified as FFSv1. So I gather that, having > not explicitely requested UFS2, it is UFS1 nonetheless. Yes. That's what newfs(8) says. > The question is: is there any problem to have a more than 1To partition > with FFSv1? Or is FFSv2 "simply" fastest, specially when using newfs, > and not trying to be smart with cylinders and grouping? The rotational stuff is gone in UFS1 level 4. See fsck_ffs(8) > If the partition is more than 2To, will the FFSv1 be unable to access > some blocks? I believe it will be fine. I have not been seeing reports of this, and I would think that if there were we would have updated the man page and adeed a warning/check in newfs. But overall, it seems that for 2T and up, the standard approach is: use UFS1 if you think you want to serve gluster from it, otherwise use UFS2 I am unclear on any really compelling arguments for UFS2 vs UFS1/ffsv2-super-block.
FFSv1 (UFS1) vs FFSv2 (UFS2)
Hello, I was assuming (don't know why) that when newfs(8)'ing a partition with more than 1To, the format would be, automatically FFSv2, FFSv1 being the default otherwise. Dumpfs(8) is a bit confusing since the superblock are said to be FFSv2, while the filesystem is identified as FFSv1. So I gather that, having not explicitely requested UFS2, it is UFS1 nonetheless. The question is: is there any problem to have a more than 1To partition with FFSv1? Or is FFSv2 "simply" fastest, specially when using newfs, and not trying to be smart with cylinders and grouping? If the partition is more than 2To, will the FFSv1 be unable to access some blocks? TIA, -- Thierry Laronde http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
