Sven, It would not be possible to implement purely in userspace today, no. The layout manipulation primitives provided by Lustre don't currently include what would be needed for a join. We would to provide some sort of new layout primitive(s) and there would be some userspace work to hook them together correctly to get the desired result.
I will defer to Andreas about what those primitives would be. -Patrick ________________________________ From: Sven Willner Sent: Thursday, March 30, 2023 1:47 AM To: Andreas Dilger Cc: Patrick Farrell; lustre-discuss@lists.lustre.org Subject: Re: [lustre-discuss] Joining files Dear Patrick and Anders, Thank you very much for your quick and comprehensive replies. My motivation behind this issues is the following: At my institute (research around a large earth system/climate model) we are evaluating using zarr (https://zarr.readthedocs.io) for outputing large multi-dimensional arrays. This currently results in a huge number of small files as the responsibility of parallel writing is fully shifted to the file system. However, after closing the respective datasets we could merge those files again to reduce the metadata burden onto the file system and for easier archival if needed at a later point. Ideally without copying the large amount of data again. For read access I would simply create an appropriate index/lookup table for the resulting large file - hence holes/gaps in the file are not a problem as such. As Patrick writes >Layout: 1 1 1 1 1 1 1 ... 20 MiB 2 2 2 2 2 2 .... 35 MiB > >With data from 0-10 MiB and 20 - 30 MiB. that would be the resulting layout (I guess, minimizing holes could be achieved by appropriate striping of the original files and/or a layout adjustment during the merge, if possible). >My expectation is that "join" of two files would be handled at the file EOF >and *not* at the layout boundary. Based on the original description from >Sven, I'd think that small gaps in the file (e.g. 4KB for page alignment, 64KB >for minimum layout alignment, or 1MB for stripe alignment) would be OK, but >tens or hundreds of MB holes would be inefficient for processing. (Andreas) Apart from archival, the resulting file would only be accessed locally in the boundaries of the orginial smaller files, so I would expect the performance costs of the gaps to be not that critical. >while I think it is possible to implement this in Lustre, I'd have to ask what >requirements are driving your request? Is this just something you want to >test, or is there some real-world usage demand for this (e.g. specific >application workload, usage in some popular library, etc)? (Andreas) At this stage I am just looking into possibilites to handle this situation - I am neither an expert in zarr nor in Lustre. If such a merge on the file system level turns out to be route worth taking, I would be happy to work on an implementation. However, yes, I would need some guidance there. Also, at this point I cannot estimate the amount of work needed even to test this approach. Would the necessary layout manipulation be possible in userspace? (I will have a look into the implementations of `lfs migrate` and `lfs mirror extend`). Thanks a lot! Best, Sven On Wed, Mar 29, 2023 at 07:41:56PM +0000, Andreas Dilger wrote: [-- Type: text/plain; charset=utf-8, Encoding: base64, Size: 8.2K --] >Patrick, >once upon a time there was "file join" functionality in Lustre that was >ancient and complex, and was finally removed in 2009. There are still a few >remnants of this like "MDS_OPEN_JOIN_FILE" and "LOV_MAGIC_JOIN_V1" defined, >but unused. That functionality long predated composite file layouts (PFL, >FLR), and used an external llog file *per file* to declare a series of other >files that described the layout. It was extremely fragile and complex and >thankfully never got into widespread usage. > >I think with the advent of composite file layout that it should be _possible_ >to implement this kind of functionality purely with layout changes, similar to >"lfs migrate" doing layout swap, or "lfs mirror extend" merging the layout of >a victim file into another file to create a mirror. > >My expectation is that "join" of two files would be handled at the file EOF >and *not* at the layout boundary. Based on the original description from >Sven, I'd think that small gaps in the file (e.g. 4KB for page alignment, 64KB >for minimum layout alignment, or 1MB for stripe alignment) would be OK, but >tens or hundreds of MB holes would be inefficient for processing. > >My guess, based on similar requests I've seen previously, and Sven's email >address, is that this relates to merging video streams from different files >into a single file? > >Sven, >while I think it is possible to implement this in Lustre, I'd have to ask what >requirements are driving your request? Is this just something you want to >test, or is there some real-world usage demand for this (e.g. specific >application workload, usage in some popular library, etc)? > >It seems possible to do this with layout manipulation similar to "lfs mirror >extend -f" (i.e. a kind of "super file append" mechanism) but would be >similarly destructive to the "victim" files appended to the original one, and >would definitely not be something that could be done while the "original" file >was actively in use. Essentially, instead of "lfs mirror extend" just >appending the victim layout to the existing file, it would need to also modify >the original layout to truncate the layout at EOF, then offset the extent >ranges in the victim layout by the current file size (rounded up to at least >64KB multiples, but preferably 1MB multiples to maintain RAID alignment). > >Is this something that you would be willing to work on with guidance for the >implementation details, or a feature request that you hope someone else will >implement? > >Cheers, Andreas > >On Mar 29, 2023, at 07:41, Patrick Farrell via lustre-discuss ><lustre-discuss@lists.lustre.org<[1]>> wrote: > >Sven, > >The "combining layouts without any data movement" part isn't currently >possible. It's probably possible in theory, but it's never been implemented. >(I'm curious what your use case is?) > >Even allowing for data movement, there's no tool to do this for you. >Depending what you mean by combining, it's possible to do this with Linux >tools (see the end of my note), but you're going to have data copying. > >It's a bit of an odd requirement, with some inherent questions - For example, >file layouts generally go to infinity, because if they don't, you will get IO >errors when you 'run off the end', ie, go past the defined layout, so the last >component is usually defined to go to infinity. > >That poses obvious questions when combining files. > >If you're looking to combine files with layouts that do not go to infinity, >then it's at least straightforward to see how you'd concatenate them. But >presumably the data in each file doesn't go to the very end of the layout? So >do you want the empty parts of the layout included? > >Say file 1 is 10 MiB in size but the layout goes to 20 MiB (again, layouts >normally should go to infinity) and file 2 is also 10 MiB in size but the >layout goes to, say, 15 MiB. Should the result look like this? > >Layout: 1 1 1 1 1 1 1 ... 20 MiB 2 2 2 2 2 2 .... 35 MiB > >With data from 0-10 MiB and 20 - 30 MiB. > >That's something you'd have to write a tool for, so it could write the data at >your specified offset for putting in the second file (and third, etc...). You >could also do something like: > >lfs setstripe [your layout] combined file; cat file 1 > combined file; >truncate [combined file] 20 MiB (the end of the file 1 layout); cat file 2 > >combined_file", etc. > >So, you definitely can't avoid data copying here. But that's how you could do >it with simple Linux tools (which you could probably have drawn up yourself >:)). > >-Patrick > >________________________________ >From: lustre-discuss <lustre-discuss-boun...@lists.lustre.org<[2]>> on behalf >of Sven Willner <sven.will...@mpimet.mpg.de<[3]>> >Sent: Wednesday, March 29, 2023 7:58 AM >To: lustre-discuss@lists.lustre.org<[1]> <lustre-discuss@lists.lustre.org<[1]>> >Subject: [lustre-discuss] Joining files > >[You don't often get email from sven.will...@mpimet.mpg.de<[3]>. Learn why >this is important at [4] ] > >Dear all, > >I am looking for a way to join/merge/concatenate several files into one, whose >layout is just the concatenation of the layouts of the respective files - >ideally without any copying/moving on the data side (even if this would result >in "holes" in the joined file). > >I would very much appreciate any hints to tools or ideas of how to achieve >such a join. As I understand that has been a `join` command for `lfs`, which >is now deprecated (however, I am not sure if a use case like mine has been its >purpose or why it has been deprecated). > >Thanks a lot! >Best regards, >Sven > >-- >Dr. Sven Willner >Scientific Computing Lab (SCLab) >Max Planck Institute for Meteorology >Bundesstraße 53, D-20146 Hamburg, Germany >_______________________________________________ >lustre-discuss mailing list >lustre-discuss@lists.lustre.org<[1]> >[5] > >Cheers, Andreas >-- >Andreas Dilger >Lustre Principal Architect >Whamcloud > > > >---------------------- > >Links: > >[1] mailto:lustre-discuss@lists.lustre.org >[2] mailto:lustre-discuss-boun...@lists.lustre.org >[3] mailto:sven.will...@mpimet.mpg.de >[4] https://aka.ms/LearnAboutSenderIdentification >[5] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org [-- Alternative Type #1: text/html; charset=utf-8, Encoding: base64, Size: 35K --] -- Dr. Sven Willner Scientific Computing Lab (SCLab) Max Planck Institute for Meteorology Bundesstraße 53, D-20146 Hamburg, Germany
_______________________________________________ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
