- 1. king -- stack dump (score: 1)
- Author: xxxxxxxx>
- Date: Fri, 25 Oct 2002 20:15:14 +0200
- ;). I just said that it spent a lot of time to delete three files. Now I know a bit more about the utilities (xfs_bmap & xfs_fsr) and take more care with
- /archives/xfs/2002-10/msg00608.html (8,212 bytes)
- 2. bout removing files (score: 1)
- Author: xxxxxxxxx
- Date: Fri, 25 Oct 2002 20:27:27 +0200
- is slower than other FS ;). I just said that it spent a lot of time to delete three files. Now I know a bit more about the utilities (xfs_bmap & xfs_fsr)
- /archives/xfs/2002-10/msg00609.html (8,688 bytes)
- 3. e is the results of my last question... (score: 1)
- Author: @xxxxxxx>
- Date: Fri, 25 Oct 2002 12:49:11 -0700
- per.c:xfs_alloc_buftarg(), (and page_buf.c:_pagebuf_page_io()) using only sector-sized buffer heads for pagebufs in the LVM case, and only aligned I/O in
- /archives/xfs/2002-10/msg00612.html (8,673 bytes)
- 4. s (score: 1)
- Author: eve Lord <lord@xxxxxxx>
- Date: 28 Oct 2002 09:51:08 -0600
- as, the longer it takes to delete it, yes. It is not the amount of space in a file, but the number of extents which matters. I can remove a 4000 extent file in less than 2 se
- /archives/xfs/2002-10/msg00657.html (9,215 bytes)
- 5. s_force_shutdown in xfs_trans_cancel (score: 1)
- Author: e@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 28 Oct 2002 11:40:46 -0800
- O Masahiro <masano@xxxxxxxxxxxxxx>. In calculating the layout of a log record for a buffer, the linux code deals with buffers which are not contiguous in memory - this only a
- /archives/xfs/2002-10/msg00666.html (8,709 bytes)
- 6. causes hangs? (score: 1)
- Author: rdmann <be@xxxxxxxxxxx>
- Date: Tue, 29 Oct 2002 11:41:20 -0800
- crazy you are for performance. ;-) -- Florin Andrei Many would-be screenwriters seem to have the impression that they can write a script based only on an idea. This is simil
- /archives/xfs/2002-10/msg00686.html (8,356 bytes)
- 7. ion to mount (score: 1)
- Author: xxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 29 Oct 2002 23:26:57 +0100
- "mount" says that xfs is not supported, can you check to see whether you got any system mes
- /archives/xfs/2002-10/msg00694.html (9,415 bytes)
- 8. y data detected" (score: 1)
- Author: xx
- Date: Fri, 25 Oct 2002 20:15:14 +0200
- exhibiting were that disk access stopped causing load-average to climb. It came back after a reboot and seems to be running fine
- /archives/xfs/2002-10/msg01387.html (8,212 bytes)
- 9. lem: mkfs.xfs failed on hppa (score: 1)
- Author: msinz@xxxxxxxxx>
- Date: Fri, 25 Oct 2002 20:27:27 +0200
- ve never had tried it. I don't use lvm heavily, so .... Maybe a good starting point would be the 1.0.5 release (the source code
- /archives/xfs/2002-10/msg01388.html (8,688 bytes)
- 10. on 2.4.18 xfs-1.1 (score: 1)
- Author: xxxxxx>
- Date: Fri, 25 Oct 2002 12:49:11 -0700
- . I just said that it spent a lot of time to delete three files. Now I know a bit more about the utilities (xfs_bmap & xfs_fsr)
- /archives/xfs/2002-10/msg01391.html (8,673 bytes)
- 11. ransaction vec. length (score: 1)
- Author: e Lord <lord@xxxxxxx>
- Date: 28 Oct 2002 09:51:08 -0600
- doing 2.5 nfsd testing, and I was sure I commited it - but it's certainly not in the repository. I'm chekcing in my version now which is functionally
- /archives/xfs/2002-10/msg01436.html (9,215 bytes)
- 12. NFS (score: 1)
- Author: x
- Date: Mon, 28 Oct 2002 11:40:46 -0800
- -- Additional Comments From sandeen@xxxxxxx 2002-10-28 08:22 -- Hi Chris - if you can decode the oops you got after you set the panic mask, that would
- /archives/xfs/2002-10/msg01445.html (8,709 bytes)
- 13. n xfs_trans_cancel (score: 1)
- Author: deen@xxxxxxx>
- Date: Tue, 29 Oct 2002 11:41:20 -0800
- ion which I have to deduce is defaulting to the left hand side in the case where there is no right hand side. In general callers of the block layer
- /archives/xfs/2002-10/msg01465.html (8,356 bytes)
- 14. Here is the results of my last question... (score: 1)
- Author:
- Date: Tue, 29 Oct 2002 23:26:57 +0100
- wnload assistant' -- where can I get this to test with? Thanks, --cw
- /archives/xfs/2002-10/msg01473.html (9,415 bytes)
- 15. Here is the results of my last question... (score: 1)
- Author: yoros@xxxxxxxxxx
- Date: Fri, 25 Oct 2002 20:15:14 +0200
- As said in the subject, related to my other mails about removing files. I have experienced that using one downloader assistant (that creates a big sparse file an then fill it to complete download), I
- /archives/xfs/2002-10/msg02166.html (8,242 bytes)
- 16. Re: Here is the results of my last question... (score: 1)
- Author: Andi Kleen <ak@xxxxxxx>
- Date: Fri, 25 Oct 2002 20:27:27 +0200
- The right thing would be to change the downloader assistant to use XFS' file preallocation ioctls so that it allocates the full space in advance. Unfortuately they are not fully implemented on linux/
- /archives/xfs/2002-10/msg02167.html (8,748 bytes)
- 17. Re: Here is the results of my last question... (score: 1)
- Author: Chris Wedgwood <cw@xxxxxxxx>
- Date: Fri, 25 Oct 2002 12:49:11 -0700
- It would be pretty cheap for the downloader to actually just touch lseek/touch ahead a few MB of each writer too, this would be almost as easy to code and would work on other filesystems. --cw
- /archives/xfs/2002-10/msg02170.html (8,759 bytes)
- 18. Re: Here is the results of my last question... (score: 1)
- Author: Russell Cattelan <cattelan@xxxxxxxxxxx>
- Date: 28 Oct 2002 09:51:08 -0600
- That would just create a file with a hole, and holes are filled in the same way appends are filled in.
- /archives/xfs/2002-10/msg02215.html (9,333 bytes)
- 19. Re: Here is the results of my last question... (score: 1)
- Author: Chris Wedgwood <cw@xxxxxxxx>
- Date: Mon, 28 Oct 2002 11:40:46 -0800
- Obviously you fill from start to end ... one pass, not per-reader/writer. --cw
- /archives/xfs/2002-10/msg02224.html (8,859 bytes)
- 20. Re: Here is the results of my last question... (score: 1)
- Author: Chris Wedgwood <cw@xxxxxxxx>
- Date: Tue, 29 Oct 2002 11:41:20 -0800
- What is this 'download assistant' -- where can I get this to test with? Thanks, --cw
- /archives/xfs/2002-10/msg02244.html (8,416 bytes)
This search system is powered by
Namazu