Make a note in the newfs.8 manual page to update the first backup
superblock location when changing the default fragment size for
the filesystem.
Reported by: O. Hartmann
to make it consistent with newfs. Document the legality of '_'
in label names in both tunefs(8) and newfs(8).
PR: 235182
Submitted by: darius@dons.net.au
Reviewed by: Conrad Meyer
MFC after: 3 days
Sponsored by: Netflix
so don't imply that. Note that if BIO_DELETE isn't supported, the
operation will fail (as opposed to writing the entire disk with
zeros). Thin storage also benefits from trim. List more accurate
reason why trim helps flash-memory.
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
go asking what debug flags to set for GEOM to make it work. Advice
them to use gpart(8) instead.
Something similar should probably done with disklabel,
but I need to rewrite the disklabel examples first.
Reviewed by: wblock@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3315
running time for a full fsck. It also reduces the random access time
for large files and speeds the traversal time for directory tree walks.
The key idea is to reserve a small area in each cylinder group
immediately following the inode blocks for the use of metadata,
specifically indirect blocks and directory contents. The new policy
is to preferentially place metadata in the metadata area and
everything else in the blocks that follow the metadata area.
The size of this area can be set when creating a filesystem using
newfs(8) or changed in an existing filesystem using tunefs(8).
Both utilities use the `-k held-for-metadata-blocks' option to
specify the amount of space to be held for metadata blocks in each
cylinder group. By default, newfs(8) sets this area to half of
minfree (typically 4% of the data area).
This work was inspired by a paper presented at Usenix's FAST '13:
www.usenix.org/conference/fast13/ffsck-fast-file-system-checker
Details of this implementation appears in the April 2013 of ;login:
www.usenix.org/publications/login/april-2013-volume-38-number-2.
A copy of the April 2013 ;login: paper can also be downloaded
from: www.mckusick.com/publications/faster_fsck.pdf.
Reviewed by: kib
Tested by: Peter Holm
MFC after: 4 weeks
want to prepare disk images for emulators (though 'makefs' in port
can do something similar).
This relies on:
+ minor changes to pass the consistency checks even when working on a file;
+ an additional option, '-p partition' , to specify the disk partition to
initialize;
+ some changes on the I/O routines to deal with partition offsets.
The latter was a bit tricky to implement, see the details in newfs.h:
in newfs, I/O is done through libufs which assumes that the file
descriptor refers to the whole partition. Introducing support for
the offset in libufs would require a non-backward compatible change
in the library, to be dealt with a version bump or with symbol
versioning.
I felt both approaches to be overkill for this specific application,
especially because there might be other changes to libufs that might
become necessary in the near future.
So I used the following trick:
- read access is always done by calling bread() directly, so we just add
the offset in the (few) places that call bread();
- write access is done through bwrite() and sbwrite(), which in turn
calls bwrite(). To avoid rewriting sbwrite(), we supply our own version
of bwrite() here, which takes precedence over the version in libufs.
MFC after: 4 weeks
replace this with vinum.4, but that's the kernel interface manual, which
is not appropriate in my understanding. I think that gvinum is a suitable
replacement for this.
PR: docs/121938
Submitted by: "Federico" <federicogalvezdurand at yahoo dot com>
MFC after: 3 days
Implement -E option which will erase the filesystem sectors before
making the new filesystem. Reserved space in front of the superblock
(bootcode) is not erased.
NB: Erasing can take as long time as writing every sector sequentially.
This is relevant for all flash based disks which use wearlevelling.
Add a new option to newfs(8), -r, to specify reserved space at the
end of the device. It can be useful, e.g., when the device is to
become a member of a gmirror array later w/o losing the file system
on it.
Document the new option in the manpage.
While I'm here, improve error handling for -s option, which is
syntactically similar to -r; and document the fact that -s0 selects
the default fs size explicitly, which can be useful, e.g., in a
menu-based wrapper around newfs(8) requiring some value be entered
for the fs size.
Also fix a small typo in the help line for -s (missing space).
Idea and initial implementation by: marck
Discussed on: -fs
Critical review by: bde
Tested with: cmp(1)
the new filesystem. This is intended for memory and vnode filesystems
that will never be fsck'ed or dumped.
Obtained from: St. Bernard Software RAPID
MFC after: 2 weeks
permits users of newfs to set the multilabel flag on UFS1 and UFS2
file systems from inception without using tunefs.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, McAfee Research
FreeBSD 5.1-RELEASE and later:
- newfs(8) will now create UFS2 file systems unless UFS1 is specifically
requested (-O1). To do this, I just twiddled the Oflag default.
- sysinstall(8) will now select UFS2 as the default layout for new
file systems unless specifically requested (use '1' and '2' to change
the file system layout in the disk labeler). To do this, I inverted
the ufs2 flag into a ufs1 flag, since ufs2 is now the default and
ufs1 is the edge case. There's a slight semantic change in the
key behavior: '2' no longer toggles, it changes the selection to UFS2.
This is very similar to a patch David O'Brien sent me at one point, and
that I couldn't find.
Approved by: re (telecon)
Reviewed by: mckusick, phk, bmah
filesystem expands the inode to 256 bytes to make space for 64-bit
block pointers. It also adds a file-creation time field, an ability
to use jumbo blocks per inode to allow extent like pointer density,
and space for extended attributes (up to twice the filesystem block
size worth of attributes, e.g., on a 16K filesystem, there is space
for 32K of attributes). UFS2 fully supports and runs existing UFS1
filesystems. New filesystems built using newfs can be built in either
UFS1 or UFS2 format using the -O option. In this commit UFS1 is
the default format, so if you want to build UFS2 format filesystems,
you must specify -O 2. This default will be changed to UFS2 when
UFS2 proves itself to be stable. In this commit the boot code for
reading UFS2 filesystems is not compiled (see /sys/boot/common/ufsread.c)
as there is insufficient space in the boot block. Once the size of the
boot block is increased, this code can be defined.
Things to note: the definition of SBSIZE has changed to SBLOCKSIZE.
The header file <ufs/ufs/dinode.h> must be included before
<ufs/ffs/fs.h> so as to get the definitions of ufs2_daddr_t and
ufs_lbn_t.
Still TODO:
Verify that the first level bootstraps work for all the architectures.
Convert the utility ffsinfo to understand UFS2 and test growfs.
Add support for the extended attribute storage. Update soft updates
to ensure integrity of extended attribute storage. Switch the
current extended attribute interfaces to use the extended attribute
storage. Add the extent like functionality (framework is there,
but is currently never used).
Sponsored by: DARPA & NAI Labs.
Reviewed by: Poul-Henning Kamp <phk@freebsd.org>
diskdrives do neither need nor want:
-O create a 4.3BSD format filesystem
-d rotational delay between contiguous blocks
-k sector 0 skew, per track
-l hardware sector interleave
-n number of distinguished rotational positions
-p spare sectors per track
-r revolutions/minute
-t tracks/cylinder
-x spare sectors per cylinder
No change in the produced filesystem image unless one or more of
these options were used.
Approved by: mckusick
16384/2048.
Following recent discussions on the -arch mailing list, involving dillon
and mckusick, this change parallels the one made over a decade ago when
the default was bumped up from 4096/512.
This should provide significant performance improvements for most
folks, less significant performance losses for a few folks and
wasted space lost to large fragments for many folks.
For discussion, please see the following thread in the -arch archive:
Subject: Using a larger block size on large filesystems
The discussion ceases to be relevant when the issue of partitioning
schemes is raised.
were only of benefit to large filesystems, which recent research
suggests is not the case, and which the original author of the text
no longer endorses.
