Re: Abysmal disk performance, how to debug?
You guys are making this harder than it needs to be. Try this: sync# To make sure nothing else is writing dd if=/dev/zero of=file bs=1M count=1024 oflag=dsync You'll get reasonable numbers this way out of dd. -J On Sat, Jan 27, 2007 at 02:43:04PM -0500, Bill Davidsen wrote: > What you want is this: > sync; > time bash -c "dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; sync" > which will actually time the write with the time command. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Abysmal disk performance, how to debug?
You guys are making this harder than it needs to be. Try this: sync# To make sure nothing else is writing dd if=/dev/zero of=file bs=1M count=1024 oflag=dsync You'll get reasonable numbers this way out of dd. -J On Sat, Jan 27, 2007 at 02:43:04PM -0500, Bill Davidsen wrote: What you want is this: sync; time bash -c dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; sync which will actually time the write with the time command. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
On Sun, Apr 10, 2005 at 10:14:55PM +0200, Pavel Machek wrote: > Hi! > > > > Oliver Neukum wrote: > > > > What is the point in doing so after they've rested on the disk for ages? > > > > > > The point is not physical access to the disk but data gathering after > > > resume or reboot. > > > > After resume or reboot normal access control mechanisms will work > > again. Those who can read a swap partition under normal circumstances > > can also read /dev/kmem. It seems to me like you are putting an extra > > lock on a window on the third floor while leaving the front door open. > > Andreas is right, his patches are needed. > > Currently, if your laptop is stolen after resume, they can still data > in swsusp image. > > Zeroing the swsusp pages helps a lot here, because at least they are > not getting swsusp image data without heavy tools. [Or think root > compromise month after you used swsusp.] > > Encrypting swsusp image is of course even better, because you don't > have to write large ammounts of zeros to your disks during resume ;-). How does zeroing help if they steal the laptop? The data is there, they can just pull the hard disk out and mirror it before they boot. The only way to improve security here is to encrypt it. Zeroing will help some if they compromise root later, but I doubt that's really worth it considering you're screwed after a root compromise anyway. -J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
On Sun, Apr 10, 2005 at 10:14:55PM +0200, Pavel Machek wrote: Hi! Oliver Neukum wrote: What is the point in doing so after they've rested on the disk for ages? The point is not physical access to the disk but data gathering after resume or reboot. After resume or reboot normal access control mechanisms will work again. Those who can read a swap partition under normal circumstances can also read /dev/kmem. It seems to me like you are putting an extra lock on a window on the third floor while leaving the front door open. Andreas is right, his patches are needed. Currently, if your laptop is stolen after resume, they can still data in swsusp image. Zeroing the swsusp pages helps a lot here, because at least they are not getting swsusp image data without heavy tools. [Or think root compromise month after you used swsusp.] Encrypting swsusp image is of course even better, because you don't have to write large ammounts of zeros to your disks during resume ;-). How does zeroing help if they steal the laptop? The data is there, they can just pull the hard disk out and mirror it before they boot. The only way to improve security here is to encrypt it. Zeroing will help some if they compromise root later, but I doubt that's really worth it considering you're screwed after a root compromise anyway. -J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [announce 0/7] fbsplash - The Framebuffer Splash
On Fri, Mar 11, 2005 at 06:03:20PM +, James Simmons wrote: > > > > > Thats why moving the eye candy console into user space is such a good > > > > idea. You don't have to run it 8) It also means that the console > > > > development is accessible to all the crazy rasterman types. > > > > > > Yep. The basic console we already have. Everyone who wants eye candy can > > > switch > > > from basic console to user space console in early userspace. > > > > > > > Heh, I'm afraid it does not work like that. Anyone who wants eye-candy > > simply applies broken patch to their kernel... unless their distribution > > applied one > > already. > > > > Situation where we have one working eye-candy patch would certainly > > be an improvement. > > Why do we need patches in the kernel. Just set you config to > CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or > vgacon. Then have a userspace app using /dev/fb and /dev/input create a > userland console. There is no need to do special hacks in the kernel. Putting it in userland would make it impossible to debug what's wrong with the system if there's a kernel error, since userland will die long before it can spit out anything useful. The primary purpose of these things is to make a distribution look pretty while booting. Lots of people complain that Linux distros look "old fashioned" or something because they don't show little dancing girls during early boot. I should think the primary features you need here are: * Can display some pretty looking thing with a logo * If there's a problem during boot (userspace error, oops, panic, etc.) then it should become a regular console able to scroll back over the boot-time spew. I don't think a user-space version can do that for anything except userspace errors, so a kernel console is better. -J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [announce 0/7] fbsplash - The Framebuffer Splash
On Fri, Mar 11, 2005 at 06:03:20PM +, James Simmons wrote: Thats why moving the eye candy console into user space is such a good idea. You don't have to run it 8) It also means that the console development is accessible to all the crazy rasterman types. Yep. The basic console we already have. Everyone who wants eye candy can switch from basic console to user space console in early userspace. Heh, I'm afraid it does not work like that. Anyone who wants eye-candy simply applies broken patch to their kernel... unless their distribution applied one already. Situation where we have one working eye-candy patch would certainly be an improvement. Why do we need patches in the kernel. Just set you config to CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or vgacon. Then have a userspace app using /dev/fb and /dev/input create a userland console. There is no need to do special hacks in the kernel. Putting it in userland would make it impossible to debug what's wrong with the system if there's a kernel error, since userland will die long before it can spit out anything useful. The primary purpose of these things is to make a distribution look pretty while booting. Lots of people complain that Linux distros look old fashioned or something because they don't show little dancing girls during early boot. I should think the primary features you need here are: * Can display some pretty looking thing with a logo * If there's a problem during boot (userspace error, oops, panic, etc.) then it should become a regular console able to scroll back over the boot-time spew. I don't think a user-space version can do that for anything except userspace errors, so a kernel console is better. -J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
