Re: Files on disk
Does that imply then that a TMC backed up sparse file could not be restored to the same device it came off of? Would TMC attempt to restore all 26G? Yes, and yes. Bitten by that one on Solaris too. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Files on disk
On Wednesday 21 July 2010 18:26, Sterling James wrote: What's compression set to? I know that has other implications, also. Look at the makesparsefile option for restore. Tivoli Storage Manager backs up a sparse file as a regular file if client compression is off. Set the compression option to yes to enable file compression when backing up sparse files to minimize network transaction time and maximize server storage space. I don't know jack about TSM, but based only on that quote and this thread so far I have to wonder what happens during a restore. If it's using compression to deal with sparse files, it's probably still compressing all those empty blocks, right? So on restore, does it decompress them and write blocks of zeros out instead of re-creating a sparse file? If that's the case, then it will still try to restore that 26GB sparse file to use 26GB of DASD, even if it compressed it down to 200MB on the server because of all the blocks of zeros in it. Has anyone investigated that problem? - MacK. - Edmund R. MacKenty Software Architect Rocket Software 275 Grove Street · Newton, MA 02466-2272 · USA Tel: +1.617.614.4321 Email: m...@rs.com Web: www.rocketsoftware.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Files on disk
Hi listers, On a SLES8 guest we have found that file /var/log/lastlog is reported to be 26G. Also the /var/log/faillog is reported to be 2G. But, the /var is located on a 3390 model 3. So that disk, that also contains other directories, is only 2.3 G. Command df shows that the / is 83% in use. How can it be that files can grow larger than the disk they reside on? And why would df report on 83% instead of 100% usage? (Yes, I know, the maintainer of this system should have setup logrotate to rotate those files. Unfortunatly he decided 6 years ago that /var/log/messages would be enough.) Met vriendelijke groet/With kind regards, Berry van Sleeuwen Flight Forum 3000 5657 EW Eindhoven ( +31 (0)6 22564276 Atos Origin http://www.atosorigin.com/ MO CF SC Mainframe Services -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ image001.gifimage003.jpgÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e m e s s a g e c o n t e n t . A l t h o u g h t h e s e n d e r e n d e a v o u r s t o m a i n t a i n a c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n i s v i r u s - f r e e a n d w i l l n o t b e l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m a n y v i r u s t r a n s m i t t e d . O n a l l o f f e r s a n d a g r e e m e n t s u n d e r w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s o f D e l i v e r y f r o m A t o s O r i g i n e x c l u s i v e l y a p p l y . T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y s u b m i t t e d t o y o u o n y o u r r e q u e s t . A t o s O r i g i n N e d e r l a n d B . V . / U t r e c h t K v K U t r e c h t 3 0 1 3 2 7 6 2
Re: Files on disk
On Wednesday 21 July 2010 05:03, van Sleeuwen, Berry wrote: On a SLES8 guest we have found that file /var/log/lastlog is reported to be 26G. Also the /var/log/faillog is reported to be 2G. But, the /var is located on a 3390 model 3. So that disk, that also contains other directories, is only 2.3 G. Command df shows that the / is 83% in use. How can it be that files can grow larger than the disk they reside on? And why would df report on 83% instead of 100% usage? Because they are sparse files. Linux only allocates blocks for a file that have actually been written, so if a process creates a file and seeks a couple of gigabytes into it before the first write, the file size is reported as over 2GB, but it really only uses the blocks actually written after that point. Use du(1) to report the actual space used by those files. IIRC, sparse files are used for these logs because they are in a kind of record-oriented format, where the position in the file is the record key. That's why you need to use last(1) and faillog(8) to look at those files: they are not plain text files the way /var/log/messages is. - MacK. - Edmund R. MacKenty Software Architect Rocket Software 275 Grove Street · Newton, MA 02466-2272 · USA Tel: +1.617.614.4321 Email: m...@rs.com Web: www.rocketsoftware.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Files on disk
Hello Edmund, Sparse files. OK. Then the next question, how can I store a 26G file in a machine that isn't that large? And to add to this, why does the filesystem backup really dump 26G into our TSM server? So it looks like the data is going somewhere. Berry. Op 21-07-10 15:41, Edmund R. MacKenty schreef: Because they are sparse files. Linux only allocates blocks for a file that have actually been written, so if a process creates a file and seeks a couple of gigabytes into it before the first write, the file size is reported as over 2GB, but it really only uses the blocks actually written after that point. Use du(1) to report the actual space used by those files. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Files on disk
RSYNC is your friend. rsync -a -S sourcedir/. targetdir/. where -S means handle sparse files intelligently. TAR also has an option for handling sparse files. -- R; On Wed, Jul 21, 2010 at 11:59, Berry van Sleeuwen berry.vansleeu...@xs4all.nl wrote: Hello Edmund, Sparse files. OK. Then the next question, how can I store a 26G file in a machine that isn't that large? And to add to this, why does the filesystem backup really dump 26G into our TSM server? So it looks like the data is going somewhere. Berry. Op 21-07-10 15:41, Edmund R. MacKenty schreef: Because they are sparse files. Linux only allocates blocks for a file that have actually been written, so if a process creates a file and seeks a couple of gigabytes into it before the first write, the file size is reported as over 2GB, but it really only uses the blocks actually written after that point. Use du(1) to report the actual space used by those files. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Files on disk
On Wednesday 21 July 2010 11:59, Berry van Sleeuwen wrote: Sparse files. OK. Then the next question, how can I store a 26G file in a machine that isn't that large? And to add to this, why does the filesystem backup really dump 26G into our TSM server? Because it isn't really using 26GB of disk space. The *length* of the file is 26GB because the program writing it seeked out that far and wrote something. But it didn't write all the data between zero and 26GB, so Linux didn't allocate disk space for the parts of the file that were never written to. Run du -h /var/log/lastlog to see just how little disk space that file uses. Here's what it says on my system, for example: # ll -h /var/log/lastlog -rw-r--r-- 1 root tty 1.2M Jul 20 08:30 /var/log/lastlog # du -h /var/log/lastlog 48K /var/log/lastlog So even though the file is 1.2MB long, it's only using up 48KB (or 12 blocks) of disk space. The file is sparse because it does not have blocks allocated for its entire length. The backup dumps a 26GB file because when a program reads a part of a sparse file that was never written, it gets back a block of all zeros. So TSM is reading all that unallocated space, and writing out lots of blocks of zeros to the backup file. Thus the backup file is not a sparse file, because TSM wrote every block of that 26GB. Perhaps there's some TSM option to get it to recognise sparse files? Rick pointed out that rsync and tar have options that deal with sparse files intelligently: when they copy a sparse file, they do not write out blocks of all zeros. Instead, they seek past such empty blocks to avoid writing to them, thus creating a sparse output file. That's how a proper Linux file copy is done. The cp command also does that. - MacK. - Edmund R. MacKenty Software Architect Rocket Software 275 Grove Street · Newton, MA 02466-2272 · USA Tel: +1.617.614.4321 Email: m...@rs.com Web: www.rocketsoftware.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Files on disk
Sparse files. OK. Then the next question, how can I store a 26G file in a machine that isn't that large? Because sparse files are just a bunch of pointers -- the data doesn't really exist. It's just diddling around with the directory inode. And to add to this, why does the filesystem backup really dump 26G into our TSM server? TSM doesn't process sparse files correctly on many platforms. In this case it's using APIs that don't recognize sparse files and so it's dumping all 26G. -- db -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Files on disk
Thank you all for your replies. It's clear to me, we were dumping zero's. Regards, Berry. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Files on disk
Does that imply then that a TMC backed up sparse file could not be restored to the same device it came off of? Would TMC attempt to restore all 26G? On 07/21/2010 12:14 PM, David Boyes wrote: Sparse files. OK. Then the next question, how can I store a 26G file in a machine that isn't that large? Because sparse files are just a bunch of pointers -- the data doesn't really exist. It's just diddling around with the directory inode. And to add to this, why does the filesystem backup really dump 26G into our TSM server? TSM doesn't process sparse files correctly on many platforms. In this case it's using APIs that don't recognize sparse files and so it's dumping all 26G. -- db -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Files on disk
On Wednesday 21 July 2010 17:48, Dave Jones wrote: Does that imply then that a TMC backed up sparse file could not be restored to the same device it came off of? Would TMC attempt to restore all 26G? I would expect so. If it doesn't know enough to preserve the sparseness of a file as it backs it up, I doubt it would be making a file sparse again upon restore just because some blocks contain all zeros. I'd look for some configuration option that makes it aware of sparse files. - MacK. - Edmund R. MacKenty Software Architect Rocket Software 275 Grove Street · Newton, MA 02466-2272 · USA Tel: +1.617.614.4321 Email: m...@rs.com Web: www.rocketsoftware.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Files on disk
I might just add that despite it's manpage assertion, rsync isn't too intelligent about it at all. My (non z) testing indicated that if you re-use the same target file, after the initial run cp is significantly more efficient. The initial run for both is comparable as the target needs to be created. Didn't test tar as it wasn't relevant (to me) at that juncture. Shane On Thu, Jul 22nd, 2010 at 3:06 AM, Edmund R. MacKenty wrote: Rick pointed out that rsync and tar have options that deal with sparse files intelligently: when they copy a sparse file, they do not write out blocks of all zeros. Instead, they seek past such empty blocks to avoid writing to them, thus creating a sparse output file. That's how a proper Linux file copy is done. The cp command also does that. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Files on disk
What's compression set to? I know that has other implications, also. Look at the makesparsefile option for restore. Tivoli Storage Manager backs up a sparse file as a regular file if client compression is off. Set the compression option to yes to enable file compression when backing up sparse files to minimize network transaction time and maximize server storage space. Thanks From: Edmund R. MacKenty ed.macke...@rocketsoftware.com To: LINUX-390@VM.MARIST.EDU Date: 07/21/2010 04:58 PM Subject: Re: Files on disk Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU On Wednesday 21 July 2010 17:48, Dave Jones wrote: Does that imply then that a TMC backed up sparse file could not be restored to the same device it came off of? Would TMC attempt to restore all 26G? I would expect so. If it doesn't know enough to preserve the sparseness of a file as it backs it up, I doubt it would be making a file sparse again upon restore just because some blocks contain all zeros. I'd look for some configuration option that makes it aware of sparse files. - MacK. - Edmund R. MacKenty Software Architect Rocket Software 275 Grove Street · Newton, MA 02466-2272 · USA Tel: +1.617.614.4321 Email: m...@rs.com Web: www.rocketsoftware.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
