LFS-SETSTRIPE(1)
π¦ lfs-setstripe β no cap, this is the layout queen
okay bestie, real talk: this is lfs-setstripe(1) from the Lustre Utilities manual, and she's a big one. She's part 1 of 3, so buckle up, hydrate, and let's get into it π
β¨ NAME β¨
lfs-setstripe β set the striping pattern of a file, or the default striping pattern of a directory. she decides how your bytes get spread across the whole filesystem. main character behaviour, honestly. π
πΈ SYNOPSIS πΈ
lfs setstripe [STRIPE_OPTIONS] DIRECTORY|FILENAME
lfs setstripe -E COMP_END [STRIPE_OPTIONS] ... DIRECTORY|FILENAME
lfs setstripe --comp-add -E COMP_END [STRIPE_OPTIONS] ... FILENAME
lfs setstripe --comp-del [-I COMP_ID|--comp-flags=COMP_FLAGS] FILENAME
lfs setstripe --comp-set [-I COMP_ID|--comp-flags=COMP_FLAGS] FILENAME
lfs setstripe -N[MIRROR_COUNT] [STRIPE_OPTIONS] DIRECTORY|FILENAME
lfs setstripe -d DIRECTORY
lfs setstripe --yaml=YAML_TEMPLATE_FILE.LYL FILENAME
lfs setstripe --copy=SOURCE_TEMPLATE_FILE FILENAME
lfs setstripe --foreign[=FOREIGN_TYPE] [--flags=HEX]
--xattr=LAYOUT_STRING FILENAME
that last one wraps onto two lines and yes, it hurts me too π copy it carefully.
π DESCRIPTION π
lfs setstripe makes a brand new FILENAME on a Lustre filesystem with the exact layout you asked for. or β plot twist β it sets the default layout for new files created inside DIRECTORY. And if DIRECTORY is the filesystem root and nothing else outranks it, that default applies anywhere in the filesystem. it's giving "I'm the blueprint for everything." π
Files with composite layouts let you hand different STRIPE_OPTIONS to non-overlapping extents of the same file. very "different vibes per region," very customizable, we stan.
Here's the inheritance lore, and yes it matters so listen up π«Ά: files inherit any options you didn't explicitly put on the command line, either from the default layout on the parent directory, or from the filesystem-wide default. New subdirectories created under the root directory will not explicitly copy the default layout at creation time β they'll implicitly inherit it at runtime instead. Sneaky but valid. β¨
Meanwhile, a default layout set on a non-root directory does get copied to any new subdirectories created inside that directory, at the moment they're created. copy-paste energy, fr fr.
π oh also,setstripecan be locked down. You can restrict it to privileged users (the ones withCAP_SYS_RESOURCE, peepsetcap(8)) by setting the parameterllite.*.enable_setstripe_gid=0. Or restrict it to an administrator group (e.g.wheel) by using that group's numeric group ID. Or set it to-1to let everyone use it β which, btw, is the default. π«£
okay now the actual sub-commands, one by one:
lfs setstripe [STRIPE_OPTIONS ...] DIRECTORY|FILENAMEβ Create a newFILENAMEwith a plain layout using whateverSTRIPE_OPTIONSyou gave it. Or, if it's an existingDIRECTORY, replace that directory's default file layout. simple, iconic, does what it says. β¨lfs setstripe -E END_OFFSET [STRIPE_OPTIONS] ... DIRECTORY|FILENAMEβ Create a new compositeFILENAMEwith one or more component layouts (whateverEND_OFFSETis marks the end of the current component). Or set/replace the default file layout on an existingDIRECTORY. multi-part masterpiece. πlfs setstripe --component-add -E END_OFFSET [STRIPE_OPTIONS] ... FILENAMEβ Add one or more components after the last component of an existing composite file that, crucially, doesn't have a component ateofyet. don't skip that condition, bestie, it's load-bearing. βlfs setstripe --comp-del [-I COMP_ID | --comp-flags COMP_FLAGS] FILENAMEβ Remove the component(s) specified by component ID or by flags, fromFILENAME. bye girl, we're deleting. πlfs setstripe --comp-set [-I COMP_ID | --comp-flags COMP_FLAGS] FILENAMEβ Set or clearCOMP_FLAGSon the specified component. π¨ heads up: this one can only be applied to mirrored files. no mirrors, no service. πlfs setstripe -N [MIRROR_COUNT] [COMPONENT_OPTIONS] DIRECTORY|FILENAMEβ Create a newFILENAMEwith the number of mirrors you asked for plus any other layout options you specified. Or set/replace the default file layout on an existingDIRECTORY. redundancy babe, we love her. πlfs setstripe -d DIRECTORYβ Delete the default layout on the specified directory. Important nuance incoming π«Ά: you do not need to delete a directory's default layout before replacing it. You only do this if the directory should revert from having its own directory-specific default back to using the global filesystem default layout stored on the root directory. it's a glow-down on purpose. π₯lfs setstripe --yaml=YAML_TEMPLATE_FILE.LYL FILENAMEβ Create a newFILENAMEusing the Lustre YAML Layout templateYAML_TEMPLATE_FILE.LYL, which you make from anEXISTING_FILElike this:
lfs getstripe --yaml EXISTING_FILE > YAML_TEMPLATE_FILE.LYL
YAML_TEMPLATE_FILE.LYL is a plain-text file that you can save and/or modify after it's created. So you build a whole complex file layout once, and then keep re-using it forever. future-proofing, slay. π
lfs setstripe --copy=SOURCE_TEMPLATE_FILE FILENAMEβ Create a new file using the same layout as an existingSOURCE_TEMPLATE_FILE. It's basically the--yamloption minus the whole intermediate.lylfile situation. lowkey the convenient one. πΈlfs setstripe --foreign[=FOREIGN_TYPE] [--flags=HEX] --xattr=LAYOUT_STRING FILENAMEβ Create a newFILENAMEwith a foreign / non-lustre layout of typeFOREIGN_TYPE(none,daos, ...) with flagsHEXand a free-format layout value ofLAYOUT_STRING. it's literally not even a lustre layout and we support it anyway. generosity. π§
π STRIPE_OPTIONS π
here come the OST stripe options, all of them, listed and explained, no skipping, no summarising, we respect the source material:
-c,--stripe-count STRIPE_COUNTβ The number of OSTs to stripe a file over.0means use the filesystem-wide default stripe count (which defaults to1), and-1means stripe over all available OSTs. go big or go home. π₯-C,--overstripe-count STRIPE_COUNTβ The number of stripes to create β and yes, it'll make> 1stripe per OST ifcountexceeds the number of OSTs in the file system.0means use the filesystem-wide default stripe count (default1). The range-1to-32means to stripe over all available OSTs in multiples of the OST count. For example,-1means one stripe per OST,-2means two stripes per OST, and so on. it's a multiplier, she's doing girl math and it's correct. β¨-S,--stripe-size STRIPE_SIZEβ The number of bytes to store on each OST before moving to the next OST. A stripe size of0means the file should use the filesystem-wide default stripe size (default4MiB). You can tack on an optional suffix to specify units in Kibi-, Mebi-, or Gibibytes. π¨ TheSTRIPE_SIZEmust be a multiple of64KiB. And values below4096are assumed to be in KiB units. don't get cute with it. π€-i,--stripe-index START_OST_IDXβ The OST index (starting at0) on which to start striping this file. ASTART_OST_IDXof-1lets the MDS choose the starting index β and this is strongly recommended, because it lets the MDS do space and load balancing as needed. let the MDS cook. π-L,--layout LAYOUT_TYPEβ The type of layout for that component. It can be one of:raid0β stripe the file data acrossSTRIPE_COUNTOST objects in units ofSTRIPE_SIZEchunks. This is the default layout if you don't specify anything. the O.G. πmdtβ place the first component of the file data on the MDT for faster access, right where the inode lives. Can be used for small files, and with composite file layouts. π¨ Themdttype may only be used for the first component of a file. TheSTRIPE_SIZEof the MDT component is always equal to the component size. There's also a per-MDT tunable parameterlod.dom_stripesizethat limits the maximum size of a DoM stripe, and you can change it on the MDS withlctl set_param lod.*.dom_stripesize=STRIPE_SIZE, whereSTRIPE_SIZEmust be a multiple of64KiBin size. peeplctl(8)for the details. π
-o,--ost OST_IDXβ Used to specify the exact stripe layout on the file system.OST_IDXis a list of OSTs referenced by their indices, specified in decimal or hex form β you can grab them with thelfs ostscommand. The list format is individual OST indices and index ranges separated by commas, e.g.1,2-4,7. You can specify the-ooption multiple times to stripe across the union of all the listed OSTs. If you combine-cwith-o, theSTRIPE_COUNTmust agree with the number of OSTs inOST_IDX. If you combine-iwith-o, theSTART_OST_IDXmust be in the OST list, and it'll be used as the index on which to start striping the file. Otherwise, striping happens in the order specified inOST_IDX. extremely precise, extremely her. π-p,--pool POOL_NAMEβ Allocate objects from the predefined OST poolPOOL_NAMEfor the layout of this file or component. You can useSTRIPE_COUNT,STRIPE_SIZE, andSTART_OST_IDXto pick a subset of the OSTs within the pool β butSTART_OST_IDXmust be part of the pool, or you get an error back. rude but fair. π You can specify a different pool for each component of a file. If no pool is specified, it gets inherited from the previous component (for later components of a composite layout), or from the parent or root directory (for plainraid0layouts, or the first component of a composite file). Usepool_name=ignoreto force a component to have no pool set (no inheritance from the last component, root, or parent). Usepool_name=''orpool_name=inherit(since Lustre 2.15) to force a component to inherit the pool from the parent or root directory instead of from the previous component. so many inheritance options bestie, pick your fighter. π¦--foreign [FOREIGN_TYPE]β The file layout is non-lustre / free-format, and of typeFOREIGN_TYPEif specified (see also the--xattrand--flagsoptions). Current known types arenoneandsymlink, and the default isnone.-x,--xattr LAYOUT_STRINGβ Mandatory non-lustre / free-format layout / LOV EA content for a foreign file. it's required, don't skip it. π-F,--flags HEXβ Optional bitmap of flags for the foreign type. sprinkle them in if you want. β
okay that's part 1 bestie, keep scrolling, there's more. π«Ά no sign-off because we are NOT done here.
π COMPONENT_OPTIONS π
okay bestie so this is the part where it gets juicy β the component-related options, all of them, laid out one by one. Also a lil life hack: every one of the --component-* options can be shortened to --comp-* if you're feeling lazy (no judgement, I get it π
).
-E,--component-end END_OFFSETβ add a brand-new component to a file, using the STRIPE_OPTIONS that come right after the-Eargument. Those options apply to the component that ends at offsetEND_OFFSETin bytes β or you can use a suffix (KMGTP) to say it in base-two units, so like256Mmeans 2^28 bytes, cute right? An offset of-1oreofmeans everything after this keeps going all the way to the end of the file. The first component starts at offset 0, and every component after that starts wherever the previous one ended, so you must list them in increasing file offset order, and it must be a multiple of64KiBso it lines up with the minimumSTRIPE_SIZEvalue. Anything below4096gets assumed to be in KiB units. β¨
The first component you specify inherits its default params from the parent directory or the root directory, just like a plain layout (as covered above π). Components after that inherit the default layout params from the component right before them. And you use multiple -E options to separate the STRIPE_OPTIONS for different regions of the file. π
heads up: if a file has no component extending toeof, writing past the end of the last component throws an error. This is genuinely useful if you wanna cap a file's size at the end of the last component you specified β or, alternatively, use--component-addto tack more components onto the end of the file.
-z,--extension-size,--ext-size EXT_SIZEβ this one modifies the-Eoption. Any component with this option set gets made as a pair of components: an extendable one and an extension one. π¦
The extendable component starts at offset 0 if it's the first component of the file β in that case it ends at offset EXT_SIZE and it gets the flag init (initialized). If it's not the first component of the file, the extendable component starts at the end of the previous component β and in that case it ends at that same offset (so it's a 0-length component).
The extension component covers the rest of the specified region, up to the END_OFFSET you gave with -E, and it gets the flag extension. Basically it holds the space that's reserved for the extendable component but not used right away β the extendable component grows by EXT_SIZE at a time until the extension component is all used up. This is how you control the space on the OSTs your stripe lives on: if one of those OSTs is low on space, the leftover extension component region gets added to the next component. lowkey genius tbh.
--ec,--ec-stripe-count DATA_STRIPES+PARITY_STRIPESβ turns on Erasure Coding (EC) for the file or directory layout. You give it the number ofDATA_STRIPESper RAID Set andPARITY_STRIPESper RAID Set, in the formatDATA+PARITYorDATA:PARITY. So for example,--ec 8+2gives you RAID Sets with 8 data stripes and 2 parity stripes each, which means you can survive up to 2 OST failures per RAID Set. π‘οΈβ¨
When you throw --ec in, a parity mirror gets created automatically, matching the structure of the data mirror via Lustre's File Level Replication (FLR) mechanism. That parity mirror is what holds the erasure coding info you'd need to reconstruct data if OSTs die.
The EC implementation right now is "read-only" or "offline" erasure coding. Any write to the file makes the parity mirror stale π and while it's stale, you cannot use that parity info for data reconstruction. To fix it you must resync the parity mirror with the lfs-mirror-resync(1) command to bring it back in sync with the data mirror. Once it's resynced, the parity mirror protects read operations, so you can recover data in case of OST failures. This behavior is identical to how non-parity Lustre mirrors work, btw. Check lfs-mirror-create(1) and lfs-mirror-resync(1) for the full tea on mirror operations. π
For data components where STRIPE_COUNT is greater than DATA_STRIPES, the data component's stripes get split into one or more independent RAID sets β each holding at most DATA_STRIPES data stripes, each with PARITY_STRIPES parity stripes. Each RAID Set is its own independent protection domain, periodt. So like, a 16-stripe RAID0 data component with --ec 8+2 gets divided into 2 RAID Sets of 8+2 (that's 4 total parity stripes across two independent domains). And a 15-stripe data component with --ec 8+2 divides into one 8+2 RAID set and one 7+2 RAID Set. π
DATA_STRIPES has to be at least 2, and PARITY_STRIPES has to be at least 1 and less than or equal to DATA_STRIPES. The supported limits are 32 data stripes and 4 parity stripes. The sum DATA_STRIPES + PARITY_STRIPES must not exceed 256 β that's a theoretical limit of the underlying Cauchy matrix construction over GF(2^8), and it applies even with --ec-expert.
For 1-stripe components, the EC mirror gets created with only 1 parity stripe (so, only single device redundancy β just one, bestie). If you need 2 (or more) device redundancy across all components, then create files with STRIPE_COUNT=2 (or more) data stripes. π
π EC Option Inheritance and Order Independence π
The --ec option can literally appear anywhere on the command line and it still applies to every component within the same mirror β because the whole point is making sure the file data can be recovered even when the PARITY_STRIPES OSTs the file uses have failed. When you give a single --ec option, it applies to all components in the parity mirror. When you use multiple --ec options, each one inherits down to subsequent components until another --ec option replaces it. And btw, the first --ec option applies to any components that came earlier in the command. π
--ec is per-mirror β it only applies inside a single mirror definition (the one set by -N). Different mirrors can have different EC configs, or no EC at all. slay. β¨
--ec-expertβ same as--ec, but it lets you use EC stripe counts that blow past the supported limits of 32 data stripes or 4 parity stripes. This one's for expert users who truly understand the performance and reliability implications, or for testing. π₯
The max allowed values are 255 for DATA and 15 for PARITY, with DATA + PARITY not exceeding 256 (the Cauchy-matrix-over-GF(2^8) limit).
--component-addβ add components to the end of an existing composite file. Note: you can't add components incrementally to the default directory layout, because the entire default layout can be replaced with a singlelfs setstripecommand. And adding components to mirrored files is not currently allowed. π«--component-delβ delete the specified components from an existing file, using either--component-id/-Ior--component-flags. Deletion has to start with the last component. The ID you give with the-Ioption is the numerical unique ID of the component, and you can grab it with thelfs getstripe -Icommand. You cannot delete components from a default directory layout, because the whole default layout can be replaced with a singlelfs setstripecall. The--component-flagsoption is for specifying a certain type of component, and the only allowed component flag for deleting is^init, which means an uninstantiated component. Also, deleting a single component from mirrored files is not currently allowed β see thelfs-mirror-split(1)command for that. π--component-flags COMP_FLAGSβ find, set, or clear flags on a specific component. The allowed flags are:initβ the component is initialized (it has allocated objects). Used together with--component-del --component-flags ^initto find uninitialized components. π«Άpreferβ the component is preferred for read/write in a mirrored file.prefrdβ the component is preferred for read in a mirrored file.prefwrβ the component is preferred for write in a mirrored file.staleβ the component has outdated data in a mirrored file. You are not allowed to set this flag on a component of the last non-stale mirror. And once a component is marked stale, you can't clear the flag directly β you needlfs-mirror-resync(1)for that. π ββοΈnosyncβ mirror components won't be resynched by default whenlfs-mirror-resync(1)runs. Handy if you wanna freeze a file mirror as an old version or a snapshot of the file.
A leading '^' in front of flags clears the flags β or finds components that don't match the flags. And you can separate multiple flags with comma(s). πΈ
-I,--component-id COMP_IDβ the numerical unique component ID, used to identify which component you're modifying.-N,--mirror-count[MIRROR_COUNT]β create a file withMIRROR_COUNTidentical replicas on the file or directory. TheMIRROR_COUNTargument is optional and defaults to 1 if you don't specify it; if you do specify it, it has to follow the-Noption with no space in between. The max possible value for the mirror count is 16. π
The STRIPE_OPTIONS specify the specific layout for the mirror. It can be a plain layout with a specific striping pattern, or a composite layout. If you don't specify them, the stripe options get inherited from the previous component. If there is no previous component, then STRIPE_COUNT and STRIPE_SIZE inherit from the filesystem-wide default values, and OST POOL_NAME inherits from the parent directory. π
You can specify multiple -N options β each with its own STRIPE_OPTIONS β if you've got a reason to want different layouts for the replicas, like flash pools and archive pools (see lfs-mirror-create(1) for the full details, bestie).
NOTE that in the current client implementation, only one replica will be written by client nodes, and the other replicas need to be resynched using the lfs mirror resync command, or an external resync agent. so don't come crying to me when your second mirror is empty π
β¨ EXAMPLES β¨
okay bestie, THIS is the part where it all comes together π literally every vibe from the flags section, in action:
lfs setstripe -S 128K -c 2 /mnt/lustre/file1
this one makes file1 striped across two OSTs, with 128KiB on each stripe. lil guy, big dreams π«Ά
lfs setstripe -d /mnt/lustre/dir
this deletes the default stripe pattern on dir. so like, any new files created in that directory will just use the filesystem global default instead. it's giving "back to factory settings" π
lfs setstripe -N2 -E 1M -E eof -c -1 /mnt/lustre/dir1
sets a default mirror layout on a directory with 2 PFL mirrors. each mirror gets the exact same specified PFL layout. no cap β¨
lfs setstripe -N -E 1M -L mdt -E eof --component-flags=prefer -p flash
-N -E 1G -c 1 -p disk -E eof -c -1 /mnt/lustre/file1
okay this one is a whole main character β β it creates a mirrored file with 2 replicas:
- the first replica uses the MDT for files smaller than
1MB, and the rest of the file lives on the flash OST pool with filesystem-wide default values. - the second replica lives on the disk OST pool, with 1 stripe for the first 1GB of the file, and then striped across all OSTs in the disk pool for the remainder of the file.
and clients will prefer the first (flash) replica for both reads and writes. obsessed π₯
lfs setstripe -E 4M -c 1 -E 64M -c 4 -E -1 -c -1 /mnt/lustre/file1
creates a file with a composite layout:
- the component has 1 stripe and covers
[0, 4MiB) - the second component has 4 stripes and covers
[4MiB, 64MiB) - the last component stripes over all available OSTs and covers
[64MiB, EOF).
lfs setstripe -E -1 -z 64M /mnt/lustre/file1
creates a file with a composite layout where component one covers [0, 64MiB) and the second component originally covers the rest, [64MiB, EOF). once written beyond 64MiB, component one gets extended to [0, 128MiB) β once written beyond 128MiB it's extended to [0, 192MiB), etc.; and the second component is shortened appropriately π¦
now the juicy part: when one of the OSTs of the first component layout is low on space β say while writing beyond 192MiB β the first component is left as [0, 192MiB), and a new component is allocated between them. its layout repeats the first component layout but is initialized on different OSTs so the full OSTs get avoided π it gets allocated and immediately extended to [192MiB, 256MiB), and then the following extension component is shortened again. teamwork, fr fr π
lfs setstripe -E 1G -z 64M -E 100G -z 256M -E -1 -z 1G /mnt/lustre/file1
composite layout time again, but make it extra:
- component one covers
[0, 64MiB) - the third component covers
[1G, 1G) - the fifth component covers
[100GiB, 100GiB)originally.
the second, fourth and sixth extension components cover the left space accordingly. the writing process is similar to above, BUT when one of the OSTs of the first component layout is low on space β e.g. while writing beyond 192MiB in the example above β the first component is left as [0, 192MiB), the second (extension) component is removed, and its range spills over to the third and fourth components: they get moved left to start at 192MiB instead of 100GiB. the third component is immediately extended and becomes [192MiB, 448MiB), and the fourth (the extension one) component becomes [448MiB, 100GiB). iconic behavior, no notes π
lfs setstripe --component-add -E eof -c 4 /mnt/lustre/file1
adds a component that starts at the end of the last existing component and runs to the end of file. π«
lfs setstripe --component-del -I 1 /mnt/lustre/file1
deletes the component with ID equal to 1 from an existing file. bye bestie π
lfs setstripe --comp-set -I 1 --comp-flags=^prefer,stale
/mnt/lustre/file1
this clears the prefer flag and sets the stale flag on file1 component ID 1. flag surgery, slay π
lfs setstripe -E 1M -L mdt -E -1 /mnt/lustre/file1
creates file1 with a Data-on-MDT layout. the first 1MiB of the file data is placed on the MDT, and the rest of the file goes on OST(s) with default striping β¨
lfs setstripe --yaml=/tmp/layout_yaml /mnt/lustre/file2
creates file2 with the layout stored in the layout template file layout_yaml β which you can make with the lfs getstripe --yaml command. template girlies stay winning π
lfs setstripe --foreign=symlink --flags=0xda08 --xattr=PUUID:CUUID
/mnt/lustre/file1
creates foreign file1 of type symlink with a non-lustre/free-format PUUID:CUUID layout / LOV EA and flags 0xda08. alien file vibes, we respect it π
lfs setstripe -E -1 -c 8 --ec 8+2 /mnt/lustre/file1
creates file1 with an Erasure Coding layout using 8 data stripes and 2 parity stripes. the file will have two mirrors: a data mirror with 8 stripes and a parity mirror with the erasure coding information. since the data component has 8 stripes and the EC specification is 8+2, this creates a single RAID Set with 8 data stripes and 2 parity stripes, providing fault tolerance for up to 2 OST failures with 25% storage overhead. math ate π₯
lfs setstripe --ec 8+2 -E -1 -c 8 /mnt/lustre/file1a
equivalent to the previous example β showing off that if only a single --ec option is specified, it applies to all components β
lfs setstripe -E 1G -c 4 --ec 4+2 -E -1 -c 8 --ec 8+2 /mnt/lustre/file2
creates file2 with a composite EC layout. the first component (0 to 1GiB) uses 4 data stripes with 2 parity stripes (4+2 EC), and the second component (1GiB to EOF) uses 8 data stripes with 2 parity stripes (8+2 EC). each component has both data and parity mirrors πͺ
lfs setstripe -E 128M --ec 8+2 -E -1 -c 4 /mnt/lustre/file2a
creates file2a with a composite EC layout where a single --ec 8+2 applies to all components. both the first component (0 to 128MiB) and the second component (128MiB to EOF) will use 8+2 EC β demonstrating that one --ec option applies to all components in the parity mirror β¨
lfs setstripe -E 128M --ec 4+2 -E 512M -E -1 --ec 8+2 /mnt/lustre/file2b
creates file2b with three components, demonstrating multiple --ec options:
- the first component (
0to128MiB) uses4+2EC. - the second component (
128MiBto512MiB) also uses4+2EC (inherited from the first--ec). - the third component (
512MiBto EOF) uses8+2EC, as specified by the second--ecoption.
inheritance but make it erasure coding π
lfs setstripe -E -1 -c 16 --ec 8+2 /mnt/lustre/file3
creates file3 with 16 data stripes divided into 2 independent RAID Sets. each RAID Set contains 8 data stripes and 2 parity stripes (8+2), for a total of 4 parity stripes across both RAID Sets. each RAID Set can tolerate up to 2 OST failures independently. redundancy queen π
lfs setstripe -E -1 -c 20 --ec 8+2 /mnt/lustre/file3a
creates file3a with 20 data stripes β which does not evenly divide into 8+2 RAID Sets. so the stripes are automatically divided into multiple RAID Sets of optimal size:
- two
7+2RAID Sets (14data stripes,4parity stripes) - one
6+2RAID Set (6data stripes,2parity stripes)
this maintains the requested level of redundancy while creating RAID Sets which are as close to the requested dimensions as possible. adaptive, fr fr π¦
lfs setstripe -E -1 -c 256 --ec-expert 64+4 /mnt/lustre/file4
creates file4 with an EC layout that exceeds the supported limits (32 data stripes, 4 parity stripes). the --ec-expert option allows the use of up to 255 data stripes and up to 15 parity stripes per RAID Set. with 256 data stripes and 64+4 EC, this creates four 64+4 RAID Sets, for a total of 16 parity stripes. this is intended for advanced users who understand the performance and reliability implications π₯
bestie, seriously β read that last sentence again. --ec-expert is for people who know what they're doing. it's giving "I've read the source code" energy, not "I saw it in a tutorial" energy π
lfs setstripe -N -E 128M -E -1 --ec 8+2 -N -E 256M -E -1
/mnt/lustre/file5
creates file5 with two mirrors. the first mirror has two components with 8+2 EC applied to both. the second mirror has two components with no EC (plain RAID0). this demonstrates that --ec is per-mirror: the --ec 8+2 only applies to the first mirror (between the first and second -N), and does not affect the second mirror. boundaries matter π
lfs setstripe -E -1 -c 8 --ec 8+2 /mnt/lustre/dir1
sets the default EC layout on dir1, so that new files created in this directory will automatically use an 8+2 EC layout with 8 data stripes and 2 parity stripes. set it and forget it, periodt β¨
π SEE ALSO π
lctl(1), lfs(1), lfs-migrate(1), lfs-mirror-create(1), lfs-mirror-split(1), lustre(7) setcap(8)
and that's the whole page bestie!! π you made it to the end, I'm so proud π this one's from Lustre, dated 2017-08-23, and it's LFS-SETSTRIPE(1) β go stripe something responsibly πβ¨π¦
π¦ where this page comes from
- ubuntu stonking: lustre-client-utils 2.17.58+dfsg-0ubuntu2 Β· GPL-2.0-only
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms