LFS-SETSTRIPE(1)

πŸ“¦ version 2.17.58, in ubuntu stonking

πŸ¦‹ 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, setstripe can be locked down. You can restrict it to privileged users (the ones with CAP_SYS_RESOURCE, peep setcap(8)) by setting the parameter llite.*.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 -1 to 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 new FILENAME with a plain layout using whatever STRIPE_OPTIONS you gave it. Or, if it's an existing DIRECTORY, 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 composite FILENAME with one or more component layouts (whatever END_OFFSET is marks the end of the current component). Or set/replace the default file layout on an existing DIRECTORY. 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 at eof yet. 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, from FILENAME. bye girl, we're deleting. πŸ’€
  • lfs setstripe --comp-set [-I COMP_ID | --comp-flags COMP_FLAGS] FILENAME β€” Set or clear COMP_FLAGS on 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 new FILENAME with the number of mirrors you asked for plus any other layout options you specified. Or set/replace the default file layout on an existing DIRECTORY. 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 new FILENAME using the Lustre YAML Layout template YAML_TEMPLATE_FILE.LYL, which you make from an EXISTING_FILE like 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 existing SOURCE_TEMPLATE_FILE. It's basically the --yaml option minus the whole intermediate .lyl file situation. lowkey the convenient one. 🌸
  • lfs setstripe --foreign[=FOREIGN_TYPE] [--flags=HEX] --xattr=LAYOUT_STRING FILENAME β€” Create a new FILENAME with a foreign / non-lustre layout of type FOREIGN_TYPE (none, daos, ...) with flags HEX and a free-format layout value of LAYOUT_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. 0 means use the filesystem-wide default stripe count (which defaults to 1), and -1 means 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 > 1 stripe per OST if count exceeds the number of OSTs in the file system. 0 means use the filesystem-wide default stripe count (default 1). The range -1 to -32 means to stripe over all available OSTs in multiples of the OST count. For example, -1 means one stripe per OST, -2 means 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 of 0 means the file should use the filesystem-wide default stripe size (default 4MiB). You can tack on an optional suffix to specify units in Kibi-, Mebi-, or Gibibytes. 🚨 The STRIPE_SIZE must be a multiple of 64KiB. And values below 4096 are assumed to be in KiB units. don't get cute with it. 😀
  • -i, --stripe-index START_OST_IDX β€” The OST index (starting at 0) on which to start striping this file. A START_OST_IDX of -1 lets 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 across STRIPE_COUNT OST objects in units of STRIPE_SIZE chunks. 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. 🚨 The mdt type may only be used for the first component of a file. The STRIPE_SIZE of the MDT component is always equal to the component size. There's also a per-MDT tunable parameter lod.dom_stripesize that limits the maximum size of a DoM stripe, and you can change it on the MDS with lctl set_param lod.*.dom_stripesize=STRIPE_SIZE, where STRIPE_SIZE must be a multiple of 64KiB in size. peep lctl(8) for the details. πŸŽ€
  • -o, --ost OST_IDX β€” Used to specify the exact stripe layout on the file system. OST_IDX is a list of OSTs referenced by their indices, specified in decimal or hex form β€” you can grab them with the lfs osts command. The list format is individual OST indices and index ranges separated by commas, e.g. 1,2-4,7. You can specify the -o option multiple times to stripe across the union of all the listed OSTs. If you combine -c with -o, the STRIPE_COUNT must agree with the number of OSTs in OST_IDX. If you combine -i with -o, the START_OST_IDX must 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 in OST_IDX. extremely precise, extremely her. 🌟
  • -p, --pool POOL_NAME β€” Allocate objects from the predefined OST pool POOL_NAME for the layout of this file or component. You can use STRIPE_COUNT, STRIPE_SIZE, and START_OST_IDX to pick a subset of the OSTs within the pool β€” but START_OST_IDX must 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 plain raid0 layouts, or the first component of a composite file). Use pool_name=ignore to force a component to have no pool set (no inheritance from the last component, root, or parent). Use pool_name='' or pool_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 type FOREIGN_TYPE if specified (see also the --xattr and --flags options). Current known types are none and symlink, and the default is none.
  • -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 -E argument. Those options apply to the component that ends at offset END_OFFSET in bytes β€” or you can use a suffix (KMGTP) to say it in base-two units, so like 256M means 2^28 bytes, cute right? An offset of -1 or eof means 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 of 64KiB so it lines up with the minimum STRIPE_SIZE value. Anything below 4096 gets 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 to eof, 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-add to tack more components onto the end of the file.
  • -z, --extension-size, --ext-size EXT_SIZE β€” this one modifies the -E option. 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 of DATA_STRIPES per RAID Set and PARITY_STRIPES per RAID Set, in the format DATA+PARITY or DATA:PARITY. So for example, --ec 8+2 gives 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 single lfs setstripe command. And adding components to mirrored files is not currently allowed. 🚫
  • --component-del β€” delete the specified components from an existing file, using either --component-id/-I or --component-flags. Deletion has to start with the last component. The ID you give with the -I option is the numerical unique ID of the component, and you can grab it with the lfs getstripe -I command. You cannot delete components from a default directory layout, because the whole default layout can be replaced with a single lfs setstripe call. The --component-flags option 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 the lfs-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 ^init to 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 need lfs-mirror-resync(1) for that. πŸ™…β€β™€οΈ
    • nosync β€” mirror components won't be resynched by default when lfs-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 with MIRROR_COUNT identical replicas on the file or directory. The MIRROR_COUNT argument is optional and defaults to 1 if you don't specify it; if you do specify it, it has to follow the -N option 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 (0 to 128MiB) uses 4+2 EC.
  • the second component (128MiB to 512MiB) also uses 4+2 EC (inherited from the first --ec).
  • the third component (512MiB to EOF) uses 8+2 EC, as specified by the second --ec option.

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+2 RAID Sets (14 data stripes, 4 parity stripes)
  • one 6+2 RAID Set (6 data stripes, 2 parity 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