Red Hat Enterprise Linux Presents (E14): RHEL Directories and Filesystems

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
[Music] good morning good afternoon good evening wherever you're hailing from welcome to another episode of red hat enterprise linux presents i am chris short executive producer of open shift tv i am here with the one and only scott mcbryan scott how are you doing today sir doing great chris looking forward to talking about some file system stuff and we'll see where that takes us yeah and i know the topic seems very rudimentary to some that might watch this channel normally but this is a foundational topic that will help everyone in the long run right like understanding the linux file system and how it's structured really helps you get a hold of linux systems in general and manage them better and also don't store stuff in var temp that'll be the one lesson you should take away from this well and and truth be told like if the audience wants to drive us down a rabbit hole let's let's totally erase it wholeheartedly yeah i am all for it right like consider this an office hour about linux file system directory structures and um we will happily take you down any rabbit hole you want to go down we are ready i don't know about happily well i'll happily do it because i i enjoy it regardless uh so um we've talked about this a while ago and it's like like i said a foundational topic that a lot of folks don't always uh have their arms around and i figured we'd start which is talking about like what that top level directory structure looks like so let me share my screen all right and you actually went above and beyond here i did yeah so um let's just take a look at that top level directory um and what i did was i just took this list of directories and i put them over here on another tab so we could just have something to like look at that's not terminal i know yeah yeah no that makes sense i like it uh and and putting chris short on the spot is always fun to do so i figured we would take turns talking about what we expect to find in each of these directories so chris i will let you go first pick pick any direction well i'll just do it in alphabetical order right like bin okay bin contains binaries that's one way to look at it right like it's it's generally right like system level binaries there's other places to put you know your personal binaries or you know um artifacts from your your your software that might be running but like this is where cat and ls and rm and all those you know like core linux commands those binaries live here and i will see your binaries go other places but called bin and raise you [Music] if you take a look at the graph environment variable every user if they log in with a bash shell and use the standard uh shell scripts that come with rel um will actually have their own personal bin directory added to their path by default nice that's amazing yeah crazy crazy um what do you what are you going to pick next like you can do alphabetically well i just said i would start alphabetically it doesn't mean we have to stick with that uh so i'll stick with that theme okay but you might get yourself in trouble later we'll see we'll see i probably will so slash dev is where we expect to find device files uh these are a logical representation of devices attached to the system so this is where we find um these special kind of files that represent hardware and generally they're indicated on whether they're a character or black device and then there's like the major and minor numbers instead of number of links and some other pieces of data about them in their inode but more more generically this is where we find device files to represent the devices attached to the system yeah remember everything in linux is kind of a file right like that's kind of the idea so you can mucky muck with it on the command line as such but there are special kinds of files that are devices all right your turn short all right so let's see uh i mean i'll just do home home is where all your users uh live essentially right like they will work inside home their home directory is theirs like unless you're root on a system one user can't look at another user's directory by default uh at least um so it's kind of like your private playground to do whatever you need to do in you'll see interestingly enough root does not live under home it lives under root we'll talk about that later but um you know your home directory will have your files in it right like if you use like the the gui for rel i forget no if you use gnome for example um that home directory is kind of like where everything is for you your downloads your documents everything that kind of deal yeah and um what goes in all these directories is dictated by a document called the linux file system hierarchy standard um and for for linux this is where user directories go for unix at large that's not always the case right so for example on my my irix box that i i love dearly but was modern 30 years ago it chose to put home directories and user share people oh or fans yeah yeah so uh but home is is where most modern distributions will put user stuff and i would like to point out that in the official docs it says home is optional um just to give you an idea of you know how sometimes there are systems that have no home directories and that should not be taken as an abnormality yeah for rel we we include it right um but but yes there could be specialized builds of other linuxes that maybe would not include that but we we always include it in our uh in our file system level for real so i'll do a twofer okay because we have lib64 and then there's also liv and they actually both pretty much hold the same thing now but that wasn't the case always yes but they're both first shared libraries and the difference between them is that uh you know once upon a time we were compiled with 32-bit binaries and libraries and then at some point we started supporting 64-bit stuff so lib64 was created to hold those and now we've kind of coalesced them back together again but i'll talk about that coalescing in a bit so lib and lib64 are for shared libraries so does this mean i should take mount and media or they are two different things they are two different things but they do use the mount command to get stuff there correct yes in most cases i feel like yeah um but anyways mount is the you know defecto point for mounting uh file systems of another variety right so you know if you have your iscsi network this would get mounted here as a subdirectory underneath mount um you know your nfs shares uh would get mounted for system use in the mount directory and notice it says m t and i'm saying mount that's because like they're one in the same kind of deal where media is a mount point for removable media so like you insert a thumb drive or a cd dvd whatever uh even certain kinds of uh card readers that kind of thing right like that'll show up in media um but it does use mount to put those things into media and media is kind of newer than uh mount in the uh directory structure by a number of years yes and and there's actually a newer one still that we now use in updating versions of gnome um now that's right i can't keep up with this stuff sometimes i know and and that's one of the things like we at red hat provide this file system for rel based off of the file system hierarchy standard and there are some times where something exists in the standard that we don't really use right but we keep it because either historically we've used it in the case of melt for example or maybe other people use it which i think may still be the case today for media because i know that our stuff that used to use it has been moved elsewhere but it's part of the standard so we comply with the standard great um we've talked about the next one on the show if we're going in line by line order here yeah i'll find the link real quick for everybody so proc is a in-memory file system it's actually not stored on disk so anything you look at in that directory is actually you're looking at um uh components in the kernel's memory in the runtime um and so there's all kinds of stuff in there we've actually done two shows on it one was yeah an overview and another one was a deeper dive and tunables that are there right but um it got its name because originally it was where we could find process information um so like when you look in there you'll see all the pids of the processes running on the system yeah home is where you make it um that's a funny funny comment i like that one uh there's the proc episode i'm dropping in the chat now and then the tunables episode i'll grab here real quick come on youtube search and we're doing that i'll just go ahead and yeah please do thank you so i i mentioned that there was a newer place that noam was using for file system removable media stuff and that's under run these are four mount points that people need during the run time of an application so when you plug a usb thumbstick into gnome that's running it's running application it's like oh i need to make a mount point to mount this usb stick that just got plugged in for my user so i can run the files application so it creates this subdirectory to run and then um attaches that device at that location nice all right so you did run i'll do boot boot is a fun one right so boot is actually like formatted differently as far as you know your petition goes sometimes um and it's supposed to sit in theory at the front of the disk but it's kind of hard like in the virtual world to imagine the front of the disk right like especially with ssds right that was because on spinning media spinning rust as i like to call it nowadays it would be faster access times so now with ssds nvme drives like the access time is consistent across the entire storage device so it doesn't really matter as much but boot is where the inet system lives uh well not all of it but some of it um and like how linux starts on your system that lives here the kernel like lives here uh and everything gets loaded at startup from boot yeah and it used to be like way way back um you put the bootloader in the master boot record under disk which was the first sector of the disk right we can't put a whole lot of smarts in one sector of space so we had to create boot and make sure that it was at the front of the disk because you could put a little binary in there to be your boot loader but it could only have so much address space so you had to store those files that it was accessing within a certain amount of your disk because it just didn't have the address space to find them if they were stored later on um that this one is one that's kind of still a little funky um because in some places like cloud images a lot of the marketplace images and stuff have moved away from this you just have the slash file system and that's it yeah um however for like disa stick compliance it requires that this be a standalone file system on a disk or partition and so when you're dealing with that you also need to think about things like space so the kernel the binary executable part of the kernel not the modules is stored here and so 10 years ago you could get away with 100 megabyte boot partition and be cool because yeah part of the kernel was like five megabytes right exactly that is not the case anymore uh so you may need several hundred megabytes for your boot file system so that you can apply update to the kernel and not have to immediately remove the old one in order to have enough space in rel when you update the kernel you will have your old copy and your new copy here unless you tell the kernel to clean up itself don't clean up the known good one first make sure the new one boots before you clean up any old ones spoken like a true systems administrator i had been bitten by this before yes uh because the boot partition was so small and then the kernel that was upgraded didn't work so yeah yeah good stuff so and the other thing that we find here is like the second stage of grub and you know the larger bootloader components that are executed from the mbr record in old bios's um so etsy is for the all the other stuff not really so that's how it was that's how it was initially done um back in like the system five and uh actually it was berkeley that started that that directory um but what has happened over time is it's become the place where we put configuration files because like you put your binaries in the bin directory and you put other files in other directories and then i was like well i need this config file where does that go yeah i'll put it in the center directory and over time that just became the place where all the configuration files went so if you're looking for config files i would look in uh slash etc etsy containers is a great directory if you're using podman or any container uh you know orchestrator or driver or anything like that uh etsy containerscontainers.com will contain all your image registries for example so that's always good to be aware of and uh you know that order and precedence matters as well so we did live we did media we did media so opt so opt like for me op is i don't know i kind of i have a love-hate relationship right like i get it opt is where you know software lands right like external packages you know blah blah blah that's where your package lands or your provided thing lands and where it's consumed from what ends up often happening in opt is you get like uh like opt-ben and doc and stuff are usually in there but then you get opt package bin and people get confused sometimes right like let's say my package is you know a go binary and that's not where the go binary goes right like opt is for specifically stuff you're deploying right like it's not necessarily the de facto place where stuff gets installed which is kind of confusing to people um but if you look at the page for op there's some very specific uh oh there's a question in here sorry does etsy stand for editable text configurations i thought it stood for etc like the the other stuff right let's see here um doesn't necessarily say that in the docs i wonder if we'd have to actually go down into like the the bowels of berkeley unix yeah maybe some old page somewhere maybe possibly it's entirely possible that that's the case but i'm not seeing anything here to indicate that that is the case oh but anyways back to opt so intentionally it was for additional software to land so like again back back in the realm of time um yes the 90s otherwise known as the 90s so if you were a unix producer you would put your binaries in bin and you would put your libraries lib but if you were an isv or a third-party developer you weren't supposed to put your stuff in those directories that was for operating system vendor stuff only right um and so they created opt to be the place where if you're adding on stuff that's where you should add it on because it was optional to the system and so because of that complex history and the fact that things like bin directories under opt were added to people's paths by default um that that line got blurred really fast over the need for ease of use so there are still some packages that will do that like a lot of the add-on software you get from ibm or oracle for example with their database suite yeah they'll put it down under opt-in so there'll be a directory in opt that says like you know name of software and then underneath of that will be bin lib you know yadda yadda for the software that goes along with that that's worth noting too that opt came from the unix land right and i don't in my early days of using linux i don't necessarily remember opt being there right it was it was but it's been there it wasn't used like it is now i guess probably the right description and even now i don't think it's really used all that often like typically where i see it is when people are building across multi architecture and they happen to support a unix flavor as well they'll use opt and then when it comes to linux they use opt to because it kind of makes sense for their packaging and sanity but a lot of stuff like if you install software off of the extra packages for enterprise linux repository for example it's not going to put it knobbed no it's going to put it in bin or lib or you know wherever else it it goes into the file system um directory structure and that's kind of just the way it is yeah so and there's not a one good approach like you know it's an operating system right there's a thousand ways to do one thing right now i will say if you're installing additional software that happens to have the same name as system provided software please put it in an opt yeah don't don't override the system no like that's yeah and we've even made that not necessarily harder in rel eight but we've we've made some very clear lines there with rail eight right like this is where system stuff belongs this is where user stuff belongs right like we've we've made clear delineations there yeah you're taking root i'm taking root so this is the root user accounts home directory we don't put it in slash home because as chris pointed out earlier it's flagged as optional um also a lot of times it's set up as a separate file system so it goes to like different storage yeah and if your system was having problems and for whatever reason that storage wasn't available when you log in as root you still need to maybe have access to your own stuff so slash root goes as part of the slash file system and goes on the storage of the slash file system other unix's will actually not put this out there so when you log in as root on uh solaris for example you get dropped into slash as your home directory which means when you download a file or your desktop wants to create things like downloads and pictures or whatever it puts to the topmost directory because that's your home directory for root um so things got kind of cluttered at that top level when you actually had someone operating his root on a box so in the file system hierarchy standard they created this subdirectory to kind of hide all that root user mess from the rest of people and and this is an interest like as we're going through these i'm pulling up the docs this is an interesting footnote on root we recommend against the root account you we recommend against using the root account for tasks that can be performed as an unprivileged user what a great idea um and that it be used solely for system administration for this reason we recommend that subdirectories for mail and other applications not appear in the root accounts home directory and that mail for administration roles such as root postmaster and webmaster be forwarded to an appropriate user what does this mean to me i read this as root is cli only don't install a gui as root right and have mail and all kinds of other stuff living under this directory because it is going to be a necessary thing for when stuff goes bump in the night you want that to be there right and only really important things should just live in root for system administration i mean but fair enough yeah i would probably be less vigorous about it because i mean that's just me and i get it um but there's a lot of like workstations that people own and i could see them maybe using root on that but again for system administration stuff i think you typically will operate on those boxes as a regular user for a whole host of reasons not just security and file ownership and a variety of other things uh so we have no we have a comment slash question um from rapscallion reeves our friend uh and we now be we might not be able to answer this because i don't know the answer maybe you just got why are bsd and linux's file trees so similar but so different i don't get why bsd has user local bin and user local etsy for example um that's just their decision making process right like there so i think it ties to the history of how we got here right so once upon a time there were two large unix distributions berkeley and system five and uh as they matured and they wanted to um woo users from one to the other or back again they had to build up this kind of cross-populated directory structure horribleness so like if you were a uh a berkeley person right because you started on solaris when it was solaris four dot something something and then your company decided that you were going to be an hp ux shop which was system five so you log into your first hp x machine you're like where is everything so hp ux or aix for that matter too from ibm they started to create these kind of additional directories to make it more comfortable for people coming from berkeley and then sun was like well i mean what if somebody goes from aix or whatever it is solaris so they started doing the same thing with the system five directories um and so when you look at the commercial unix's i think a lot of them end up cross-populating between the berkeley and system five standards and then linux comes along and it's the same deal they have to appeal to people who maybe were used to working in a variety of unixes so they created this much more amalgam of directory structures but bsd is still a legitimate unix distribution with a couple of different flavors and they've stayed pretty true to their their file system hierarchy standard that they minted back in the day and so that's i think why you find like freebsd or netbsd have a different directory structure because there wasn't this pressure to create these additional directories to create comfort for people moving between distros right cool uh so i got a question here um you'll know this better than i do uh when is well will rel migrate to butter fs so we shipped uh butter fs aztec preview for the duration of route 7 right and then you'll notice that it's not included with rel8 so there's still work going on in butter fs yeah it certainly needs to be more stable yeah like the biggest thing about file systems uh nobody likes it when their data vanishes [Music] so you know you have to make sure that that stuff is rock solid like somebody was uh just recently was asking me about file system driver for linux and we do not ship that as part of route um you can get it in places like i think people may have it yeah um so you can get a module and it'll plug into your kernel and stuff but that's because there is a extremely unlikely um situation where you can lose data and so if you're mounting an ntfs file system into your linux directory structure and then data starts vanishing no bueno yeah um yeah people tend to frown on that especially in the enterprise distribution world we like to make sure your data is as stable and intact as possible as we're going about making your operating systems so yeah i mean there's there's a lot of work being done in butter fs fedora is using butter fs i'm using that screen right there i'm using butter fs um i don't have anything of significance that i cannot replace easily on that box for example though as a result and i don't think butterfs is like ridiculously unstable but i mean even if it's a very unlikely situation yeah yeah so i know that our product manager for file system um stuff is continued to keep an eye on rfs um so i i don't remember if we put it into centos stream nine centos stream nine um was had their first build just like a week ago and that should be a pretty good representation of what we expect to land in in rel next year when we release rail line um i have not looked for butt rfs but that would be if i was going to look to see if it was maybe going to land in there that's right first mm-hmm yeah check out cintel stream see where because that's the progression right fedora center stream rel yep ta-da yeah and centos stream um keeps a pretty close relationship with rel so when you're looking at centos stream you're looking at a pretty good representation of what you can expect in the next version of makes sense all right so you're up with s-ben oh uh so espin is another one of those throwbacks i feel like um maybe maybe not uh i don't remember which came first so you said bin was for things like ls yeah yeah s bin is for things like f disk there you go and like system binaries right like stuff that's going to muck with the system itself and again this is another one like opt where it's like was this here when i was using like red hat enterprise linux 5 when i first started it absolutely it definitely was and it came from uh the need to have like back in the day you partition the hell out of disks um nowadays you might not so much it might be one or two partitions right um so you would want s-bend to be in a similarly fast you know file system slash space on disk as boot was right because you're gonna need fsck at boot time sometimes right so like there was that for a little bit and people kind of went away from that as this got faster so more generically it's for systems administration binaries so like partitioning disks yeah exactly um and like way way back we could do things like change the permissions on it so that people couldn't access them but uh we also for regular users don't include the s-pen directories on their path so when they're looking for commands they probably won't find these with things like tab completion because they're not system administrators they don't get the aspen directory and then over time we we figured out that that wasn't a great plan because people would still add it to their path and find it anyway so we started to do things like building checks to the system administration binaries to be like if your user id is then please partition the disk if not start up in a read-only mode and tell the user that they can't do anything but look but no touching right yeah question in chat here um are some links between ben and espin do they exist like they are between ben and user ben that's a good question so i was gonna handle the sim link question at the end because that's a change that we made in rel seven yes uh and i was gonna flip back over to my actual box speaking of which i should probably uh yeah flip back over show us all right uh so if you look in our our directory here right you'll see that bin lib lip 64 and s been are all symbolic likes and they point to their user counterparts so this is a functionality of combining the linux file system hierarchy standard out of berkeley and system five so in berkeley they put all of the bin lib s bin at the top level root directory whereas in system 5's directory file system hierarchy standard they put it under user for unix system resources and then it became like well as time went on and we started to cross populate between those two directory structures sometimes a thing wouldn't bend and sometimes it went user pin or sometimes a thing went into s bin and other times it would be user spin so we ended up having to start adding those directories to like both sets of those directories to everyone's paths um and then in rel seven we just went ahead and merged them together and created these sim links so in reality everything in rel goes into user um and then if your package when you're you know installing an rpm or whatever says slash bin that's fine it just follows the sim link and puts it in user bin so um yeah we created those sim links to still maintain that compatibility and i missed this question from rapscallion reeves one thing i still don't understand about fedora 34 and butterfs since compression is enabled by default if you check the encryption box during f34 install will that mess you up how can butter fs encrypt compress encrypted data let's and let's not conflate compression and encryption right they are vastly different things um an encryption algorithm masks the data using the you know prescribed algorithm compression uses a different algorithm to make more space on the disk right like that's essentially the way to look at it but rfs uses compression in the file system which should be in theory more efficient um than like using external processes to make that compression happen and then decompress and recompress in and out kind of deal um but encryption can happen before or after compression right like there's no wrong order to do that in but you have to decrypt a disk before you can load it so it usually is compressed and then encrypted correct or am i wrong in saying that i think i think that's mostly mostly right okay um the one place where you might get into some weirdness is if you encrypt first then compress because oh yeah when you compress stuff things like text compress really well right whereas binary does not text very well and so i wonder if you encrypt something if it changes the data to the point where it doesn't compress very well anymore um i think there's a point of diminishing returns right yeah for sure um where now we're getting two questions about the difference between x4 and butter fs what's more secure what's more performant is so i am not a butt rfs user i am i mean i am a rfs experimenter at this point right like i don't know enough about it to be like it's definitively more performant than x4 or xfs or anything else for that matter and i would say that i just knowing myself i probably won't pay much attention to rfs until it comes back in a row yeah so i mean and the only reason i'm using it is because it's the fault in the f-34 uh and 33 and 32. um but yeah that's a good question uh i'll try to find some research on that for y'all so we should probably ask bob handlin uh long time watchers may recognize him from like our first or second actually second or third show because he came on to talk to us about kpatch maybe i think but he is also the data services product manager for rel um so he's the one when i mentioned somebody was keeping an eye on it he's the one who's keeping an eye on it and that might be our next stop to ask these kinds of questions yeah see like here's a performance like a really good one from furronex uh but it's from 2019 so it's like i don't know if that date is still good uh let's see yeah and then in terms of like file system on rel um by default we use xfs and but we still offer ext4 as an alternative and the big difference there is things like i know to look up tables and numbers of files that one can have in a directory um xfs just does better with small files lots and lots of small files than ext4 but is about the same for normal file workloads so we have um some folks that like run their web store using rel um and there they have like a gajillion tiny files because like each product review is a file right each like suggested product might be a file um and so for each product that they sell in their store and there might be like thousands of files underneath of it um so we we use xfs because of that right yeah i mean and i linked an article in chat folks from fedora magazine about choosing between butter fs and x4 so yeah and it talks about lvm in there too and how you can use multiple devices so yeah you can do a lot with the two file systems as you see fit yeah and if you're interested in things like compression and saving space you may also be interested in taking a look at vdo which is the virtual data optimizer um that comes with rel essentially uses data deduplication yes um to right to not store the same bits on disk multiple times but all right so i think it's my turn um srv is one that we don't really use in rel um but like debian distros use a lot um so it's for server or service files um but yeah we we don't really make use of it in row yeah i mean it's rationale the main purpose of specifying this is so that users may find the location of data files for a particular service you know there's there's a lot of caveats under here um like some stuff should be in var lib right like so yeah just keep that in mind uh so the syst directory is one i am i will have to admit i'm not familiar with sys directory uh and i'm searching the docs for it right now so we talked about it a couple weeks ago we were talking about tunables because like proc it is an in-memory file system right and so um you have things there like um your preference for using huge pages in the kernel or power consumption settings or block device tools this is the system settings for all the things yes yes sorry okay now it came back to me then why don't you take 10. okay temp uh is almost exactly what you think it's for it is for temporary files but the different temp has a relative in var temp which will actually purge itself on boot so if you're putting files in temp they will last through a reboot where var temp they may or may not depending upon the os yes depending on the os for rel they do persist across right but like temp um there is a service that's run as a crown job right that will remove stuff from vartep as well um and i use temp for like literally the output of scripts that i'm running as like a diagnostic type thing or if i'm running an ansible playbook and i need to actually write a file to disk and then i know i'm going to get rid of it later temp is where i do it right so anything that i know i'm going to have to have some output that has to land on disk and then i want to erase it later that's what temp is for yeah and i think um by default stuff gets erased from temp every 10 days if it's not been used oh really thanks yeah thanks to the temp watch service that's running through chron um so basically it like goes into temp and looks at all the files and directories in there and looks the last access timestamp and the last access timestamp was older than 10 days ago it gets killed off and removed nice yeah user we talked about a little bit already unix system resources and we merged that together with ben lib and s bin so this is where our binaries and libraries actually get stored for rail 7 and rally var is one of my favorite directories because there's so much going on right like uh you know var logs var cash var crash var lib var lock like everything kind of like running on the system is under like the outputs of that is all under var right so if you're looking for logs somewhere go look in var logs if you're looking for lock files that you're trying to get rid of go looking for lock um but the the the purpose of like var itself it contains variable data files that's literally why it's called var um this includes like spool directories so print jobs emails things like that uh administrative logging data transient files temporary files uh one thing to point out is that like some things living in var aren't shareable right across uh systems so just keep that in mind right like you don't want to mount var log to the same thing on every system unless you have a way to take care of that output you know right like your logs are structured in a certain way to identify themselves as coming from certain systems right otherwise it's just going to be a massive mess for yourself to clean up yeah and we actually have a service to to do that now yeah if you use arsys log or syslog ng you can have the logging service on your individual boxes congregate all of those into a specific system and it takes care of like creating a subdirectory under our log with each system's sub name or ip and then puts all the stuff that it got from them there but you know if you want to get a good did you say temp is mounted in ram no we did not say tempest mounted it is not mounted in ram no uh it is all disk um sorry there's questions that i'm missing because i'm so focused on you right now you're engrossed in the conversation well i'm i'm trying to keep my place in the slides here uh if that makes sense um but yeah like var shoot i was just slipped my brain i i spent a lot of time in var working with databases for example right like that's where your data from your databases will land um and you want to make sure that that far directory especially for that database is fast very fast right like you want var to kind of be your fastest disk at times for this reason yeah i think that that like finishes all of our directories so let's um does so let's get all right let's just get all these questions answered um would you consider testing zfs on fedora i mean maybe so zfs is not um it's not open source well or there's it's not open source with a license that we can run a distributor or something there is an open zhs i think that is making the rounds lately but there's still some licensing stuff that needs to be taken care of around zfs i mean it i love the file system right like we one of my first jobs out of the military we had an oracle storage array that's the only thing oracle we bought because it used zfs um and it's a really impressive file system but it is very tightly uh licensed in the sense of like it's incompatible with uh open source software to some extent um so yeah that's just something to keep in mind linux has something for zfs like it's making its way out into the world um so just keep that in mind it's and i thought that butterfest an attempt to reinvent that wheel in a more friendly way yeah like one that was not intellectually encumbered right um and that's kind of the idea um but yeah uh oh boy so one of my co-workers just got another one of my co-workers riled up about butter fs so maybe they'll be joining the call here or the channel here in a second to talk about things um but yeah so we'll see um what other questions we got i'd really like to see butterfest be the new zfs yes i would too um we covered the ram thing i thought exported things like nfs should come from slash srv sort of like the opposite of mount well that's a good point um where do nfs mounts land typically so it depends on what you're trying to share right if you were trying like back in the day we would do things like nfs share our user directory because we would install matlab on a server and we want other client boxes to be able to mount and execute it locally and so we we share user as an nfs share i think the biggest thing on rel for nfs is making sure that it's got the right sc linux contexts to be shared yes um so yeah i think i still end up putting stuff under mount yeah me too just so that i can context it correctly and update my um selinux policy so that it knows that things in that directory gets get done like that but you could do the same thing in in srv um if that's what you want to do all right i did have one it's kind of like there's there's the directory structure which follows you know a thing a standard um [Music] but you can deviate from that standard and some of that standard is optional and so forth so on do okay here's another question do you use x4 or butter fs in your daily life i don't i used butter yeah i was about to say i'm pretty sure you're using xfs just from previous conversations so i have used xfs for a long time and i've only switched over to butter fs recently that's just because i'm using fedora more and you know rel less here in the house um but that doesn't mean that like when i muck with servers i'm probably touching xfs uh in general nowadays i feel like so chris yes sir looking at this uh top level directory i'm using colorized ls output do you know why temp is green temp is green because it has a special mount i'm sorry just ls-ld temp and you'll see why um it has the t at the end there the the wt the sticky bit sticky bits yes that thing i forget i always remember it from the mod but never like not the numbers the words right like i memorized the numbers back in the day where other people memorize the words for change mob um yeah so so temp because it's shared by a lot of different processes a lot of different people is sticky meaning that anybody can do it anyone can write well this is sticking in this way yeah anyone can write to it but the sticky bit says that uh only the owner of a file or directory may remove it so while normally anybody that has write permission on directory can add or delete files from it in a sticky directory anyone can add files but only the user owner of a file can delete it verify having the file stuck in the directory until someone wants to get rid of it yeah um doesn't this also mean that it will inherit the these settings all the way down no matter how many directories you create underneath it that is uh the ownership well right sgid there you go yeah yeah that will that will propagate the group owner all the way through it when you get in the sticky bits things get sticky yeah well and like how do they apply to files versus directories right exactly they behave differently and i will say that the sticky bit on files on executables and linux is not honored all right so so here it is you ready scott i'm ready all right andrew sullivan showed up i guess instead of christian hernandez uh so andrew says i probably unfairly shy away from butter fs as a result of the now quite old data corruption bugs i stopped paying attention to it back then but i understand there's quite a few commercial products using it now including synology he thinks that's interesting to learn if that's the case if your synology box is running butter fs let me know i mean that's fair we in technology tend to have really long memories yeah yeah so things like i was just talking to somebody about uh satellite six oh yeah okay and they were they were like uh it's like but but it's fine now that was a long time ago 6.1 or whatever yeah yeah so synology has a page about how butterfs protects your company's data next generation file system delivers data integrity and efficient snapshots the snapshotting is what everybody seems to like the most about butterfs does xfs perform better than x4 kind of depends on the workload depends on the workload every every performance use case is going to be workload dependent yeah so literally every one so xfs does better for stupid amounts of small files at one point it actually was able to actually store more files at the directory level so like in in ext i don't remember the version uh you could only have sixty four thousand five hundred thirty five files under directory before it would like oh yeah that's right yeah um and xfs like it's ridiculous amounts that i would challenge someone to actually achieve um it's like millions of files in that in a single directory level and i can retrieve it but because it's better at looking up and retrieving those tiny large amounts of files that's kind of what sweet spot oh right it does about the same as the other file systems for just normal files to my own can we touch on redirect on right um oh you're talking about uh data duplication yeah yeah yeah yeah um so i actually uh actually have a lot about that yeah that's what i figured that's why i asked it is written by sean o'keefe i think who is the product owner for for this technology so this we're doing reducing operational storage costs with vdo and essentially it's like installing vdo and actually using it to figure out how much data is really being stored when you um are interacting with the video devices so um we don't have time to go through all that at the top of the hour but yeah um vdo is implemented through a kernel module so you want to make sure that you are running the same kernel module that you have on your running kernel and so whenever this provisions you'll see that very first command here is the yum install and it has a video version and i actually specify the version in the command and the kvdo kmod also has a version that i specify because it all has to match the currently running kernel right so if i do a umay r um i wonder if this will work let's see well there you go something's happening i think maybe not nope well it may be installed let's see if it actually works the um the lab vendor actually rebuilt my labs without me asking them to a newer version a newer update release of rel83 so it's like 834 um and i did not go through and test all the labs after that we're about to update them to rel 8.4 because that was released today yes so i was waiting for you to say that it's been waiting a long time too it's like is he really going to sit on this all the whole episode sorry not thinking no you're fine uh we mentioned it on an earlier show so that's what made me uh like be like oh i'm gonna mess with scott um but yes rel 8.4 was released today uh just a few hours ago as a matter of fact um so yeah go check it out tires on it on your desk systems please it is working so that is the right uh the right kernel module and video version uh normally when you run the video command it'll like error if you have the wrong if you have a mismatch for your module number nice so um but yeah the video stats is the command that like shows you how much you're using um and as you're like storing files that'll report on how much is being used and that's where you can track the data deduplication that's being managed exactly awesome cool so i think um yeah i thought we were gonna call it a day yeah i hope this was educational for folks right like if you have any questions uh feel free to reach out to me short at redhat.com or chrisshort on twitter um and you know we're very happy to have you here for this episode and we look forward to seeing you tomorrow at 9 00 a.m to talk about same show different name the data services office hour so yes see y'all then and thank you scott for a fun episode yet again thanks chris well next time we'll try and get a guest so in a couple weeks we'll do a guest yeah all right cool see y'all then take it easy everybody you
Info
Channel: OpenShift
Views: 265
Rating: 5 out of 5
Keywords:
Id: ezjnTyTbfNM
Channel Id: undefined
Length: 62min 54sec (3774 seconds)
Published: Wed May 19 2021
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.