+ _ _
+ | | | |
+ | |_ _ ___| |_ _ __ ___
+ | | | | / __| __| '__/ _ \
+ | | |_| \__ | |_| | | __/
+ |_|\__,_|___/\__|_| \___|
+
+Lustre is an open-source, distributed parallel file system designed for
+scalability, high-performance, and high-availability.
+
+Lustre is purpose-built to provide a coherent, global POSIX-compliant
+namespace for very large scale computer clusters, including the world's
+largest supercomputer platforms.
+
+It can support hundreds of petabytes of data storage and hundreds of
+gigabytes per second in simultaneous, aggregate throughput.
+
+
+More information about Lustre:
+ http://www.lustre.org/
Many resources for using, configuring, and troubleshooting Lustre are at:
http://wiki.lustre.org/
++-----------+
+| Community |
++-----------+
+
The low-volume list for announcements of new releases is at:
http://lists.lustre.org/listinfo.cgi/lustre-announce-lustre.org
The generic Lustre discussion mailing list is available at:
The Lustre developer mailing list is at:
http://lists.lustre.org/pipermail/lustre-devel-lustre.org
-Instructions for building, configuring and running Lustre:
+To report bugs, please visit:
+ https://jira.whamcloud.com/
+
+The official repository is hosted at:
+ https://git.whamcloud.com/
+
++----------------------+
+| Building and Testing |
++----------------------+
+
+Detailed instructions for building, configuring and running Lustre:
http://wiki.lustre.org/Compiling_Lustre
and
https://wiki.whamcloud.com/display/PUB/Getting+started+with+Lustre.
+
+To build Lustre:
+
+ bash autogen.sh
+ ./configure
+ make
+
+To play with a test Lustre filesystem:
+
+ ./lustre/tests/llmount.sh
+
+To clean up:
+
+ ./lustre/tests/llmountcleanup.sh
+
++--------------+
+| Contributing |
++--------------+
+
Instructions for contributing patches for Lustre:
http://wiki.lustre.org/Submitting_Changes
and
http://wiki.lustre.org/Using_Gerrit
+
The Lustre Coding Style Guidelines can be found at:
http://wiki.lustre.org/Lustre_Coding_Style_Guidelines
The Lustre Test Script Style Guidelines can be found at:
http://wiki.lustre.org/Lustre_Script_Coding_Style
+
In order to improve the quality of patches submitted to the Lustre tree,
it is possible to automatically check every patch and commit against the
Lustre Coding Guidelines. To do this, run in the top-level lustre/ tree:
+++ /dev/null
-tbd Sun Microsystems, Inc.
- * version 2.0.0
-
-Severity : enhancement
-Bugzilla : 19856
-Description: Add LustreNetLink, a kernel-userspace communcation path. Add
- ulinux dir for Linux userspace tools.
-
-Severity : normal
-Bugzilla : 20878
-Description: Replace LustreNetLink with kernel_user_comm based on pipes
-
--------------------------------------------------------------------------------
-
-2008-07-15 Sun Microsystems, Inc.
- * version 1.8.0
-
-new libcfs module
+++ /dev/null
-2006-10-31 - Moved to autoconf
+++ /dev/null
-To report bugs, please visit https://jira.whamcloud.com/
+++ /dev/null
-BUILDING LUSTRE
----------------
-
-You must already have a Lustre-patched kernel, which is outside of the
-scope of this document. For more information on this process, see the
-web sites below. Also consider downloading a pre-packaged Lustre
-kernel and utilities from https://downloads.whamcloud.com/
-
-To build:
- bash autogen.sh
- ./configure --with-linux=/usr/src/lustre_patched_kernel_tree
- make
-
-To play with Lustre:
- cd tests
- sh llmount.sh
-
-To clean up:
- sh llmountcleanup.sh
-
-More information about Lustre:
- http://www.lustre.org/
-
-Feedback:
- lustre-discuss@lists.lustre.org
-
-- The Lustre Team -
DIST_SUBDIRS := $(ALWAYS_SUBDIRS) $(SERVER_SUBDIRS) $(CLIENT_SUBDIRS)
-EXTRA_DIST = BUGS kernel_patches BUILDING
+EXTRA_DIST = kernel_patches
--- /dev/null
+.TH llverfs 8 "2023 Apr 23" Lustre "configuration utilities"
+.SH NAME
+llverfs - filesystem verification tool for ldiskfs based on ext3vt
+.SH SYNOPSIS
+.BI llverfs
+.RB [ -c
+.I CHUNKSIZE_MB
+.RB ]
+.RB [ -h ]
+.RB [ -o
+.IR OFFSET_KB ]
+.RB [ -l "] [" -p "] [" -r ]
+.RB [ -s
+.IR SIZE_MB ]
+.RB [ -t
+.IR TIMESTAMP ]
+.RB [ -v "] [" -w ]
+.I DEVICE
+.SH DESCRIPTION
+This program tests the correct operation of large filesystems and
+the underlying block storage device(s).
+This tool has two working modes:
+
+In full mode, the program creates a subdirectory in the test
+filesystem, writes n (files_in_dir, default=32) large (4GB) files to
+the directory with the test pattern at the start of each 4KB block.
+The test pattern contains a timestamp (to detect data written in a prior
+run), relative file offset and per-file unique identifier (inode number,
+to detect data written to the wrong location on disk). This continues
+until the whole filesystem is full and then the tool verifies that the data
+in all of the test files is correct.
+
+In partial mode, the tool creates test directories with the
+EXT2_TOPDIR_FL flag set (if supported) to spread the directory data
+around the block device instead of localizing it in a single place.
+The number of directories equals to the number of block groups in the
+filesystem (e.g. 65536 directories for 8TB ext3/ext4 filesystem) and
+then writes a single 1MB file in each directory. The tool then verifies
+that the data in each file is correct.
+.SH OPTIONS
+.TP
+.BR -c | --chunksize " \fICHUNKSIZE_MB"
+IO chunk size in megabytes (default=1), with optional KMG suffix.
+.TP
+.BR -h | --help
+Display a brief help message.
+.TP
+.BR -l | --long | --full
+Run a full check, 4GB files with 4k blocks
+.TP
+.BR -o | --offset " \fIOFFSET_KB"
+offset of IO start in kilobytes (default=0), with optional KMGTP suffix.
+.TP
+.BR -p | --partial
+Run a partial check, with 1MB files
+.TP
+.BR -r | --read
+Run test in read (verify) mode only, after having run the test in
+.B -w
+mode previously. The flag
+.B --timestamp
+is also needed in this case, using the timestamp printed out during the
+.B --write
+run.
+.TP
+.BR -s | --filesize " \fISIZE_MB"
+File size in megabytes to use for the test, with optional KMGTP
+suffix. The default is 4096MB.
+.TP
+.BR -t | --timestamp " \fITIMESTAMP"
+Set test start time as printed at the start of a previously interrupted test.
+This is to ensure that read phases (or multiple read phases) after a separate
+write phase will be able to check the validation data.
+(default=current time())
+.TP
+.BR -v | --verbose
+Run test in verbose mode, listing each read and write operation.
+.TP
+.BR -w | --write
+Run test in write (test-pattern) mode (default run both read and write)
+.SH SEE ALSO
+.BR llverdev (8)
+++ /dev/null
-FILESYSTEM VERIFICATION TOOL. ( ext3vt )
-==========================================
-
-Building tool:
- To build this tool you just need to invoke make at command prompt.
- e.g. $ make
-
- this will compile the sources and build ext3vt in this directory.
-
-Usage:
-Syntax:
-
-./ext3vt [OPTION]... <filesystem path> ...
-
-[OPTION]
- -t {seconds} for --timestamp, set test time(default=current time())
- -o {fileOffset} for --fileOffset, full path of file from which tests should start
- -r run test in read (verify) mode
- -w run test in write (test-pattern) mode (default=r&w)
- -v for verbose
- -p for --partial, for partial check (1MB files)
- -l for --long, full check (4GB file with 4k blocks)
- -c for --chunksize, IO chunk size (default=1048576)
- -h display this help and exit
- --help display this help and exit
-
-Guide lines for using this tool:
- It is expected that ext3vt tool will be run on large size
-filesystem (TB), So it is always better to run ext3vt tool in verbose mode,
-So that one can easily restart device testing from the point at which it
-had stoped.
-for example:
-
- [root@Matrix ext3vt]# ./ext3vtnew -v -f -w --timestamp=1145009417 /mnt/store/
- Timestamp: 1145009417
- write File name: /mnt/store/dir00004/file005
-
-If due to some reason sombody breaks execution at this point then one can
-easily restart device from the same point by picking the same file offset
-displayed in by verbose as explained below.
-
- [root@tucker ext3vt]# ./bdevt -v -f -w --fileOffset=/home/dir00004/file005
- --timestamp=1145009417 /mnt/store/
- Timestamp: 1145009417
- write File name: /mnt/store/dir00008/file007
- write complete
- [root@tucker ext3vt]#
-One can use similar things for read only and read write modes also.
+++ /dev/null
-1. How to build .xml configs:
-The various .xml configs in the tests/ directory are built by running the
-corresponding .sh script. The .sh script runs a series of lmc (Lustre make
-config) commands in order to build up an XML file. It is much easier to
-simply edit a .sh script and rebuild your XML config file than trying to
-edit the XML directly.
-
-For a loopback setup with a mounted filesystem, you could do something like:
-
- sh local.sh
- ../utils/lconf --reformat local.xml
-
-This will configure an MDS, an OBD/OST, and a filesystem client all running
-on the same system and communicating over the TCP loopback interface. If
-the --reformat option is given, then the OST and MDS devices will be
-formatted. This is required the first time you set up the system, or if
-you think you have corrupted the filesystems after you hit a bug.
-
-A more complex configuration, using a separate host for each of the MDS,
-OBD/OST, and filesystem client functions is in uml.sh. It configures 3
-systems, and the OST system (uml2) serves up multiple OST devices, and
-the client accesses these via a logical object volume (LOV) driver (which
-essentially stripes both of the OST devices into a single storage device.
-
-This configuration could be run on any 3 systems with the following commands:
-
- sh uml.sh
- system1# ../utils/lconf --reformat --node uml1 uml.xml
- system2# ../utils/lconf --reformat --node uml2 uml.xml
- system3# ../utils/lconf --node uml3 uml.xml
-
-The "--node <name>" parameter tells lconf to use the configuration for
-the node "name" in the XML configuration file. If the hostnames were
-already "uml1", "uml2", and "uml3", then the "--node" parameter would
-not need to be given. The internals of lconf and portals handle the
-configuration details for setting up netowrking.
-
-2. runregression-net.sh and runregression-brw.sh
-
-This test performs raw block and attribute requests against a real or
-"null" OST device. It is useful for generating isolated load on the
-OST device, while avoiding the need to run tests through the filesystem.
-This can be useful for testing the network part of Lustre in isolation,
-or doing RPC and bulk I/O performance tests against an OST.
-
-If things are alright it goes through a series of tests single threaded,
-multithreaded, using getattr and brw (both read and write, with single
-page and vector I/O, doing basic data checking of each page).
-
-You can create a simple echo client by running the "llecho.sh" to
-run the tests locally (over TCP loopback), or edit llecho.sh to
-specify the SERVER and CLIENT names. You would then set up as normal:
-
- # if you are using a remote server, first run:
- server# ../utils/lconf echo.xml
-
-Configure the client (or if you are running a single system only):
-
- client# ../utils/lconf echo.xml
- client# sh runregression-net.sh
-
-3. runtests
-
-The runtests script does a series of simple file-based tests using a
-filesystem. You need to have an XML file as appropriate for your setup
-(one or more hosts, including an MDS, one or more OSTs, and a mountpoint).
-If the MDS and/or OST is on a remote machine, configure them first:
-
- ../utils/lconf --reformat <conf>.xml
-
-On the client machine, the runtests script needs the XML configuration
-file as a command-line parameter, as it mounts and unmounts the filesystem
-several times during the test in order to verify that the data is still
-there as expected (ensures that it makes it to disk instead of just into
-the filesystem cache). If you are running on only a single machine, you
-can just use runtests directly. If this is only a client machine, the
---reformat parameter is not needed (it will not do anything).
-
- sh runtests [--reformat] <conf>.xml
-
-This creates a few simple files and directories first, and then untars
-a copy of the /etc filesystem into the Lustre filesystem. It then does
-data verification both before and after the filesystem is remounted, and
-finally deletes all of the files and verifies that the amount of space
-left in the filesystem is (nearly) the same as it was before the test.
-/*
- * GPL HEADER START
- *
- * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 only,
- * as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License version 2 for more details (a copy is included
- * in the LICENSE file that accompanied this code).
- *
- * You should have received a copy of the GNU General Public License
- * version 2 along with this program; If not, see
- * http://www.gnu.org/licenses/gpl-2.0.html
- *
- * GPL HEADER END
- */
+// SPDX-License-Identifier: GPL-2.0
+
/*
* Copyright (c) 2007, 2010, Oracle and/or its affiliates. All rights reserved.
* Use is subject to license terms.
*
* Copyright (c) 2011, Intel Corporation.
+ *
*/
+
/*
* This file is part of Lustre, http://www.lustre.org/
*
* lustre/utils/llverfs.c
*
- * Filesystem Verification Tool.
- * This program tests the correct operation of large filesystems and
- * the underlying block storage device(s).
- * This tool have two working modes
- * 1. full mode
- * 2. partial mode
- *
- * In full mode, the program creates a subdirectory in the test
- * filesystem, writes n(files_in_dir, default=32) large(4GB) files to
- * the directory with the test pattern at the start of each 4kb block.
- * The test pattern contains timestamp, relative file offset and per
- * file unique identifier(inode number). This continues until the
- * whole filesystem is full and then the tool verifies that the data
- * in all of the test files is correct.
+ * Filesystem Verification Tool: this program tests the correct operation of
+ * large filesystems and the underlying block storage device(s). For more
+ * information, see the llverfs.8 man page.
*
- * In partial mode, the tool creates test directories with the
- * EXT3_TOPDIR_FL flag set (if supported) to spread the directory data
- * around the block device instead of localizing it in a single place.
- * The number of directories equals to the number of block groups in the
- * filesystem (e.g. 65536 directories for 8TB ext3/ext4 filesystem) and
- * then writes a single 1MB file in each directory. The tool then verifies
- * that the data in each file is correct.
*/
#ifndef _GNU_SOURCE
git://git.whamcloud.com / fs / lustre-release.git / commitdiff