Re: the idea of /fastboot ?
2012/10/11 Boudewijn Dijkstra sp4mtr4p.boudew...@indes.com: What about init.8 and init.c? They also mention fastboot. You're right, those were missing since i redirected output of cvs diff into a wrong file from sbin/init because of typo. i should triple-read before sending, thanks for the note. :) -Artturi -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (Remove the obvious prefix to reply privately.)
Re: the idea of /fastboot ?
Op Wed, 10 Oct 2012 03:43:35 +0200 schreef Artturi Alm artturi@gmail.com: 2012/10/10 Philip Guenther guent...@gmail.com: On Tue, Oct 9, 2012 at 5:01 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: Yes, it is a relic. You may take action against it, Ted. Don't forget to also remove the shutdown(8) bits that use it. Philip Guenther was bored, does this miss anything? Index: rc.8 Index: pathnames.h Index: shutdown.8 Index: shutdown.c Index: rc What about init.8 and init.c? They also mention fastboot. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (Remove the obvious prefix to reply privately.)
Re: the idea of /fastboot ?
ÓÒÅÄÁ, 10 ÏËÔÑÂÒÑ 2012 Ç. ÐÏÌØÚÏ×ÁÔÅÌØ Nick Holland ÐÉÓÁÌ: On 10/09/2012 12:55 PM, éÌØÑ ûÉÐÉÃÉÎ wrote: Hello! I'm investigating /etc/rc script. And I found the following there: if [ -e /fastboot ]; then echo Fast boot: skipping disk checks. elif [ X$1 = Xautoboot ]; then echo Automatic boot in progress: starting file system checks. hmm... if I put /fastboot, no filesystem will be checked ? so says the code, yes. how it supposed to work for non-nfs filesystems ? properly? they'll be not checked, too? Just one more question. If /fastboot presents, filesystem won't be checked, right? But how does fsck detects if there's /fastboot? Is it possible thing to do without actually mount it? Is it possible to mount dirty filesystem in read-only mode ? If not, it doesn't make sense at all.
Re: the idea of /fastboot ?
On Thu, Oct 11, 2012 at 05:10:19PM +0600, ??? wrote: ?, 10 ??? 2012 ?. Nick Holland ?: On 10/09/2012 12:55 PM, ??? wrote: Hello! I'm investigating /etc/rc script. And I found the following there: if [ -e /fastboot ]; then echo Fast boot: skipping disk checks. elif [ X$1 = Xautoboot ]; then echo Automatic boot in progress: starting file system checks. hmm... if I put /fastboot, no filesystem will be checked ? so says the code, yes. how it supposed to work for non-nfs filesystems ? properly? they'll be not checked, too? Just one more question. If /fastboot presents, filesystem won't be checked, right? But how does fsck detects if there's /fastboot? Is it possible thing to do without actually mount it? fsck does not do anything with /fastboot. The rc script (which calls fsck) does that. During boot, the / filesystem is initially mounted read-only, and then is possibly checked by the rc script. After that, the root filesystem ro status is updated to rw. Is it possible to mount dirty filesystem in read-only mode ? If not, it doesn't make sense at all. Yes, you can mount dirty filesystem with -f. Even read-write iirc. Very dangerous. -Otto
Re: the idea of /fastboot ?
On Thu, Oct 11, 2012, at 07:10 AM, Илья Шипицин wrote: ÓÒÅÄÁ, 10 ÏËÔÑÂÒÑ 2012 Ç. ÐÏÌØÚÏ×ÁÔÅÌØ Nick Holland ÐÉÓÁÌ: On 10/09/2012 12:55 PM, éÌØÑ ûÉÐÉÃÉÎ wrote: Hello! I'm investigating /etc/rc script. And I found the following there: if [ -e /fastboot ]; then echo Fast boot: skipping disk checks. elif [ X$1 = Xautoboot ]; then echo Automatic boot in progress: starting file system checks. hmm... if I put /fastboot, no filesystem will be checked ? so says the code, yes. how it supposed to work for non-nfs filesystems ? properly? they'll be not checked, too? Just one more question. If /fastboot presents, filesystem won't be checked, right? But how does fsck detects if there's /fastboot? Is it possible thing to do without actually mount it? Is it possible to mount dirty filesystem in read-only mode ? If not, it doesn't make sense at all. Dude, stop worrying about it. It is deprecated. Unless you put it there it will never be there.
Re: the idea of /fastboot ?
Илья Шипицин chipits...@gmail.com writes: [...] Just one more question. If /fastboot presents, filesystem won't be checked, right? That's what's supposed to happen. Else /fastboot wouldn't exist, I guess. But how does fsck detects if there's /fastboot? Is it possible thing to do without actually mount it? How would one access the fsck executable? Or the /etc/fstab file? Is it possible to mount dirty filesystem in read-only mode ? If not, it doesn't make sense at all. Then there seems to be only one option. :) -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: the idea of /fastboot ?
2012/10/11 Otto Moerbeek o...@drijf.net On Thu, Oct 11, 2012 at 05:10:19PM +0600, ??? wrote: ?, 10 ??? 2012 ?. Nick Holland ?: On 10/09/2012 12:55 PM, ??? wrote: Hello! I'm investigating /etc/rc script. And I found the following there: if [ -e /fastboot ]; then echo Fast boot: skipping disk checks. elif [ X$1 = Xautoboot ]; then echo Automatic boot in progress: starting file system checks. hmm... if I put /fastboot, no filesystem will be checked ? so says the code, yes. how it supposed to work for non-nfs filesystems ? properly? they'll be not checked, too? Just one more question. If /fastboot presents, filesystem won't be checked, right? But how does fsck detects if there's /fastboot? Is it possible thing to do without actually mount it? fsck does not do anything with /fastboot. The rc script (which calls fsck) does that. During boot, the / filesystem is initially mounted read-only, and then is possibly checked by the rc script. After that, the root filesystem ro status is updated to rw. thank you. it is clear now. very similar to Linux and FreeBSD. Is it possible to mount dirty filesystem in read-only mode ? If not, it doesn't make sense at all. Yes, you can mount dirty filesystem with -f. Even read-write iirc. Very dangerous. I'm struggling with 7Tb filesystems, it takes about 30 minutes to check them in case of cold reset. Too much. Very too much. and currently, no journals or anything else which could speed up 7Tb filesystems check ? -Otto
Re: the idea of /fastboot ?
... I'm struggling with 7Tb filesystems, it takes about 30 minutes to check them in case of cold reset. Too much. Very too much. and currently, no journals or anything else which could speed up 7Tb filesystems check ? Almost always (in my mind/experience), file systems that big are bad design. Break your system into chunks, you will end up much happier, and I suspect your users will be, too. Advanced file systems have costs that have to be considered in system design. ZFS is everyone's favorite file system at the moment, but having played with it a bit, even if it re-released with a ISC/BSD license (don't wait up), I doubt it would ever be accepted into OpenBSD -- it's a knobfest, it's anything BUT set it and ignore it; it's job security for people setting up such systems. In your case...if you have multiple 500GB or 1TB file systems, you can hopefully mount most of them R/O, and not have to worry about fsck times at all. Nick.
Re: the idea of /fastboot ?
Is it possible to mount dirty filesystem in read-only mode ? If not, it doesn't make sense at all. Yes, you can mount dirty filesystem with -f. Even read-write iirc. Very dangerous. I'm struggling with 7Tb filesystems, it takes about 30 minutes to check them in case of cold reset. Too much. Very too much. and currently, no journals or anything else which could speed up 7Tb filesystems check ? man newfs, in particular the -i option. What does 'df -hi' say about your filesystem?
Re: the idea of /fastboot ?
On Thu, Oct 11, 2012 at 10:09:50AM -0400, Nick Holland wrote: Almost always (in my mind/experience), file systems that big are bad My /usr/ports/mind/experience appear to be broken..
Re: the idea of /fastboot ?
2012/10/11 Jan Stary h...@stare.cz Is it possible to mount dirty filesystem in read-only mode ? If not, it doesn't make sense at all. Yes, you can mount dirty filesystem with -f. Even read-write iirc. Very dangerous. I'm struggling with 7Tb filesystems, it takes about 30 minutes to check them in case of cold reset. Too much. Very too much. and currently, no journals or anything else which could speed up 7Tb filesystems check ? man newfs, in particular the -i option. What does 'df -hi' say about your filesystem? # df -hi Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd0a 377G2.7G356G 1% 158121 24804949 1% / /dev/sd1a 6.7T331G6.1T 5%8041 228037269 0% /big
Re: the idea of /fastboot ?
On Thu, Oct 11, 2012 at 5:24 AM, Eric Furman ericfur...@fastmail.net wrote: On Thu, Oct 11, 2012, at 07:10 AM, Илья Шипицин wrote: ÓÒÅÄÁ, 10 ÏËÔÑÂÒÑ 2012 Ç. ÐÏÌØÚÏ×ÁÔÅÌØ Nick Holland ÐÉÓÁÌ: how it supposed to work for non-nfs filesystems ? properly? they'll be not checked, too? Just one more question. If /fastboot presents, filesystem won't be checked, right? But how does fsck detects if there's /fastboot? Is it possible thing to do without actually mount it? Is it possible to mount dirty filesystem in read-only mode ? If not, it doesn't make sense at all. Dude, stop worrying about it. It is deprecated. Unless you put it there it will never be there. I recall seeing a script called fastboot that looked something like: #!/bin/sh touch /fastboot sync sync halt Not sure what OS that was but I know the fastboot command was present in 4.2 BSD and SunOS 4.1.3.
Re: the idea of /fastboot ?
2012/10/11 Nick Holland n...@holland-consulting.net ... I'm struggling with 7Tb filesystems, it takes about 30 minutes to check them in case of cold reset. Too much. Very too much. and currently, no journals or anything else which could speed up 7Tb filesystems check ? Almost always (in my mind/experience), file systems that big are bad design. Break your system into chunks, you will end up much happier, and I suspect your users will be, too. Advanced file systems have costs that have to be considered in system design. ZFS is everyone's favorite file system at the moment, but having played with it a bit, even if it re-released with a ISC/BSD license (don't wait up), I doubt it would ever be accepted into OpenBSD -- it's a knobfest, it's anything BUT set it and ignore it; it's job security for people setting up such systems. In your case...if you have multiple 500GB or 1TB file systems, you can hopefully mount most of them R/O, and not have to worry about fsck times at all. Nick. there are http access logs for half an year. it's easier to rotate them on a single filesystem from many points of view, we also share it via samba (very tricky to share many chunks). and it is bad idea to mount access logs R/O. difficult to rotate.
Re: the idea of /fastboot ?
On Thu, Oct 11, 2012 at 09:22:13PM +0600, ??? wrote: 2012/10/11 Jan Stary h...@stare.cz Is it possible to mount dirty filesystem in read-only mode ? If not, it doesn't make sense at all. Yes, you can mount dirty filesystem with -f. Even read-write iirc. Very dangerous. I'm struggling with 7Tb filesystems, it takes about 30 minutes to check them in case of cold reset. Too much. Very too much. and currently, no journals or anything else which could speed up 7Tb filesystems check ? man newfs, in particular the -i option. What does 'df -hi' say about your filesystem? # df -hi Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd0a 377G2.7G356G 1% 158121 24804949 1% / /dev/sd1a 6.7T331G6.1T 5%8041 228037269 0% /big Relatively few very big files. What's the fragment and block size used on this filesystem? # dumpfs /dev/rwd1a | grep ^[bf]size -Otto
Re: the idea of /fastboot ?
On Thu, Oct 11, 2012 at 09:29:50PM +0600, �?л�?�? Шипи�?ин wrote: there are http access logs for half an year. it's easier to rotate them on a single filesystem from many points of view, we also share it via samba (very tricky to share many chunks). and it is bad idea to mount access logs R/O. difficult to rotate. Bad design totally! I remember struggling with backup/restore times to satisfy SLA with huge filesystems having many files... And those were logs. One of proposals we did was to split filesystem into smaller ones and keep old logs on filesystems with read-only. Backup would be skipped, and restore (in this it was TSM) would be much faster if image would be used. j.
Re: the idea of /fastboot ?
2012/10/11 Jiri B ji...@devio.us On Thu, Oct 11, 2012 at 09:29:50PM +0600, �л�� Шипи�ин wrote: there are http access logs for half an year. it's easier to rotate them on a single filesystem from many points of view, we also share it via samba (very tricky to share many chunks). and it is bad idea to mount access logs R/O. difficult to rotate. Bad design totally! I remember struggling with backup/restore times to satisfy SLA with huge filesystems having many files... And those were logs. One of proposals we did was to split filesystem into smaller ones and keep old logs on filesystems with read-only. Backup would be skipped, and restore (in this it was TSM) would be much faster if image would be used. j. they are not old logs. generally, today's log is access.log, yesterday's log is access.log.0 and so on. every rotate renames all the logs. older logs are removed. too many tricks with r/o filesystems. also, when dealing with rotating logs within single filesystem, it's cheap, data is not moved. and what if I want to move/rotate many-many-gigabytes logs in case of better design when there're many chunks ? I guess it is hard (and pretty useless) operation from filesystem point of view. ok, I can change configs of web-server to store logs in different location every day. you call it better design ??
Re: the idea of /fastboot ?
On 10/11/2012 01:15 PM, Илья Шипицин wrote: 2012/10/11 Jiri B ji...@devio.us On Thu, Oct 11, 2012 at 09:29:50PM +0600, Ã?лÑ?Ñ? ШипиÑ?ин wrote: there are http access logs for half an year. this is a trivial case where using multiple file systems works wonderfully. it's easier to rotate them on a single filesystem from many points of view, easier ONLY in the didn't have to think about anything sense. Not in the I'll be ripping my hair out over and over again sense. Doing it wrong is usually very easy...initially. we also share it via samba (very tricky to share many chunks). actually, no. /log shared here. Only this is shared. /log/a (full, ro) /b (full, ro) /c (partly full, rw) /d (empty, waiting to be used, rw) /curr - sym link to the active chunk -- in this case, /log/c /smb/[a..d] are individual file systems. and it is bad idea to mount access logs R/O. difficult to rotate. actually, your archival copies should be RO, if you are required to retain them for legal or security reasons. You don't want them changing...you probably want secure hashes made to prove they didn't change. Bad design totally! I remember struggling with backup/restore times to satisfy SLA with huge filesystems having many files... And those were logs. One of proposals we did was to split filesystem into smaller ones and keep old logs on filesystems with read-only. Backup would be skipped, and restore (in this it was TSM) would be much faster if image would be used. j. they are not old logs. generally, today's log is access.log, yesterday's log is access.log.0 and so on. every rotate renames all the logs. older logs are removed. too many tricks with r/o filesystems. also, when dealing with rotating logs within single filesystem, it's cheap, data is not moved. and what if I want to move/rotate many-many-gigabytes logs in case of better design when there're many chunks ? I guess it is hard (and pretty useless) operation from filesystem point of view. incorrect. ok, I can change configs of web-server to store logs in different location every day. you call it better design ?? First solution that leaps to my mind: move your logging to syslog, and send the syslog output to another machine. Now, the availability of your logging system doesn't impact the availability of your webserver. Set up your logging server to log to /log/curr. That's a symlink to a particular chunk of disk. At midnight, you have a little script run, it looks to see if you are within a couple days of being out of disk space on the current archive chunk, if so, you change the symlink (note files already open on the old one will stay open, be ready for that) to the next recording partition. (note: this symlink could also point to a directory within the partition). You can do this in a fixed rotation, I prefer to have a predefined list of use this next, as I've had to off-line storage that I wasn't likely to need, but needed to retain. Another solution: If you don't like remote syslogging (i.e., you absolutely have to retain every line of access, you can't tolerate losing log data when you reboot the log machine, and you don't want to use a buffering log agent app), you could simply scp off the old log files. Generate an sha256 hash for the file when it is rotated out, and when you see the hash, copy the file and its hash over to the log storage machine, verify the hash, and if it matches, delete it from the source machine. If it doesn't match, re-copy the file next time 'round. Really, simple stuff. Much simpler than trying to manage data in one big chunk. What do you plan to do when 7TB isn't enough to retain your required six months of data? How do you back it all up? How do you restore it when the array barfs? If you wish to upgrade your logging capability, build out a new logging system, point the systems at it, mothball the old system and when your retention period is over, wipe the old system (look ma! no copying terabytes of data!). I know some people trying to manage many terabytes of fast-moving data in one chunk. They started with FreeBSD and ZFS, but had problems with it (and a definite Linux bias), so they jumped to Linux, but again are finding Big File Systems are difficult. Would be so much easier for so many reasons if they just chunked their data across multiple file systems... Ah well... Nick.
Re: the idea of /fastboot ?
I'm struggling with 7Tb filesystems, it takes about 30 minutes to check them in case of cold reset. Too much. Very too much. and currently, no journals or anything else which could speed up 7Tb filesystems check ? man newfs, in particular the -i option. What does 'df -hi' say about your filesystem? # df -hi Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/sd0a 377G2.7G356G 1% 158121 24804949 1% / /dev/sd1a 6.7T331G6.1T 5%8041 228037269 0% /big That makes you prepared for having 228037269 inodes on that file systems. Also, that makes you eligible for a fsck that long. there are http access logs for half an year. Let's say half a year is 180 days; let's say you rotate daily. Am I right at thinking that you want to be prepared to keep and rotate the http logs of about 1266873 machines daily for the next 180 days? Since when have you accumulated the 8041 inodes that are there now? If you know in advance this filesystem is gonna store apache logs, how big is your typical daily log? From your numbers (331G occupied by 8041 files), it's about 44M per file. How big a block/fragment size do you use on this filesystem then?
Re: the idea of /fastboot ?
On 10/11/12 22:27, Nick Holland wrote: On 10/11/2012 01:15 PM, Илья Шипицин wrote: 2012/10/11 Jiri B ji...@devio.us On Thu, Oct 11, 2012 at 09:29:50PM +0600, Ã?лÑ?Ñ? ШипиÑ?ин wrote: there are http access logs for half an year. this is a trivial case where using multiple file systems works wonderfully. it's easier to rotate them on a single filesystem from many points of view, easier ONLY in the didn't have to think about anything sense. Not in the I'll be ripping my hair out over and over again sense. Doing it wrong is usually very easy...initially. we also share it via samba (very tricky to share many chunks). actually, no. /log shared here. Only this is shared. /log/a (full, ro) /b (full, ro) /c (partly full, rw) /d (empty, waiting to be used, rw) /curr - sym link to the active chunk -- in this case, /log/c /smb/[a..d] are individual file systems. and it is bad idea to mount access logs R/O. difficult to rotate. actually, your archival copies should be RO, if you are required to retain them for legal or security reasons. You don't want them changing...you probably want secure hashes made to prove they didn't change. Bad design totally! I remember struggling with backup/restore times to satisfy SLA with huge filesystems having many files... And those were logs. One of proposals we did was to split filesystem into smaller ones and keep old logs on filesystems with read-only. Backup would be skipped, and restore (in this it was TSM) would be much faster if image would be used. j. they are not old logs. generally, today's log is access.log, yesterday's log is access.log.0 and so on. every rotate renames all the logs. older logs are removed. too many tricks with r/o filesystems. also, when dealing with rotating logs within single filesystem, it's cheap, data is not moved. and what if I want to move/rotate many-many-gigabytes logs in case of better design when there're many chunks ? I guess it is hard (and pretty useless) operation from filesystem point of view. incorrect. ok, I can change configs of web-server to store logs in different location every day. you call it better design ?? First solution that leaps to my mind: move your logging to syslog, and send the syslog output to another machine. Now, the availability of your logging system doesn't impact the availability of your webserver. Set up your logging server to log to /log/curr. That's a symlink to a particular chunk of disk. At midnight, you have a little script run, it looks to see if you are within a couple days of being out of disk space on the current archive chunk, if so, you change the symlink (note files already open on the old one will stay open, be ready for that) to the next recording partition. (note: this symlink could also point to a directory within the partition). You can do this in a fixed rotation, I prefer to have a predefined list of use this next, as I've had to off-line storage that I wasn't likely to need, but needed to retain. Another solution: If you don't like remote syslogging (i.e., you absolutely have to retain every line of access, you can't tolerate losing log data when you reboot the log machine, and you don't want to use a buffering log agent app), you could simply scp off the old log files. Generate an sha256 hash for the file when it is rotated out, and when you see the hash, copy the file and its hash over to the log storage machine, verify the hash, and if it matches, delete it from the source machine. If it doesn't match, re-copy the file next time 'round. Really, simple stuff. Much simpler than trying to manage data in one big chunk. What do you plan to do when 7TB isn't enough to retain your required six months of data? How do you back it all up? How do you restore it when the array barfs? If you wish to upgrade your logging capability, build out a new logging system, point the systems at it, mothball the old system and when your retention period is over, wipe the old system (look ma! no copying terabytes of data!). I know some people trying to manage many terabytes of fast-moving data in one chunk. They started with FreeBSD and ZFS, but had problems with it (and a definite Linux bias), so they jumped to Linux, but again are finding Big File Systems are difficult. Would be so much easier for so many reasons if they just chunked their data across multiple file systems... Ah well... Nick. Only thing I find annoying is that I tend to run out of partitions... :-P /Alexander
Re: the idea of /fastboot ?
On Wed, Oct 10, 2012 at 02:44:32PM +0600, ??? wrote: ?, 10 ??? 2012 ?. Nick Holland ?: On 10/09/2012 12:55 PM, ??? wrote: Hello! I'm investigating /etc/rc script. And I found the following there: if [ -e /fastboot ]; then echo Fast boot: skipping disk checks. elif [ X$1 = Xautoboot ]; then echo Automatic boot in progress: starting file system checks. hmm... if I put /fastboot, no filesystem will be checked ? so says the code, yes. how it supposed to work for non-nfs filesystems ? properly? they'll be not checked, too? I think I'm missing part of your question...but the answer is in the code, which you are already reading. I meant, in case of NFS you don't need to fsck at all. However, there's no need to indicate such case. mount already knows if there nfs stuff. Often, on my diskless client (every mount is NFS), I'll put an immuable /fastboot on the server in the NFS root directory. It saves the machine from downloading and executing one small program that would do nothing. On some extremely slow arch, there's a noticable difference. (But OpenBSD discontinuated that arch. Still bitter about it.) You don't normally fsck an nfs mount (that advisory has always satisfied my curiosity sufficiently, I've never actually tried it. I probably should). fsck does not do the actual file system checks. That's the job for the fsck_FILESYSTEMTYPE programs. Only fsck_ffs, fsck_ext2fs and fsck_msdos exists on OpenBSD. Every other type of filesystem can not be checked.
Re: the idea of /fastboot ?
ÓÒÅÄÁ, 10 ÏËÔÑÂÒÑ 2012 Ç. ÐÏÌØÚÏ×ÁÔÅÌØ Nick Holland ÐÉÓÁÌ: On 10/09/2012 12:55 PM, éÌØÑ ûÉÐÉÃÉÎ wrote: Hello! I'm investigating /etc/rc script. And I found the following there: if [ -e /fastboot ]; then echo Fast boot: skipping disk checks. elif [ X$1 = Xautoboot ]; then echo Automatic boot in progress: starting file system checks. hmm... if I put /fastboot, no filesystem will be checked ? so says the code, yes. how it supposed to work for non-nfs filesystems ? properly? they'll be not checked, too? I think I'm missing part of your question...but the answer is in the code, which you are already reading. I meant, in case of NFS you don't need to fsck at all. However, there's no need to indicate such case. mount already knows if there nfs stuff. You don't normally fsck an nfs mount (that advisory has always satisfied my curiosity sufficiently, I've never actually tried it. I probably should). is mount able to work with dirty filesystem ? for some definition of work with -- default is to refuse to mount dirty file systems. what will happen if I put /fastboot and cold reset (which leaves filesystems dirty) occures ? try it and find out? /fastboot is a marker to indicate the system was shut down cleanly, not a user-knob to twist for giggles. If you deliberately place a marker that is supposed to indicate the file system was shut down cleanly when it wasn't, you will break things. The good news is, you get to keep all the pieces. The other good news is it will be fairly easy to fix. I got an idea. It won't help to mount dirty filesystems (like error-behavour flag in case of ext4), it is just a relic, which was occasionly removed :) Great news. Nick.
the idea of /fastboot ?
Hello! I'm investigating /etc/rc script. And I found the following there: if [ -e /fastboot ]; then echo Fast boot: skipping disk checks. elif [ X$1 = Xautoboot ]; then echo Automatic boot in progress: starting file system checks. hmm... if I put /fastboot, no filesystem will be checked ? how it supposed to work for non-nfs filesystems ? is mount able to work with dirty filesystem ? what will happen if I put /fastboot and cold reset (which leaves filesystems dirty) occures ? Cheers, Ilya Shipitsin
Re: the idea of /fastboot ?
On 10/09/2012 12:55 PM, Илья Шипицин wrote: Hello! I'm investigating /etc/rc script. And I found the following there: if [ -e /fastboot ]; then echo Fast boot: skipping disk checks. elif [ X$1 = Xautoboot ]; then echo Automatic boot in progress: starting file system checks. hmm... if I put /fastboot, no filesystem will be checked ? so says the code, yes. how it supposed to work for non-nfs filesystems ? properly? they'll be not checked, too? I think I'm missing part of your question...but the answer is in the code, which you are already reading. You don't normally fsck an nfs mount (that advisory has always satisfied my curiosity sufficiently, I've never actually tried it. I probably should). is mount able to work with dirty filesystem ? for some definition of work with -- default is to refuse to mount dirty file systems. what will happen if I put /fastboot and cold reset (which leaves filesystems dirty) occures ? try it and find out? /fastboot is a marker to indicate the system was shut down cleanly, not a user-knob to twist for giggles. If you deliberately place a marker that is supposed to indicate the file system was shut down cleanly when it wasn't, you will break things. The good news is, you get to keep all the pieces. The other good news is it will be fairly easy to fix. Nick.
Re: the idea of /fastboot ?
On Tue, Oct 09, 2012 at 22:55, Илья Шипицин wrote: Hello! I'm investigating /etc/rc script. And I found the following there: if [ -e /fastboot ]; then echo Fast boot: skipping disk checks. elif [ X$1 = Xautoboot ]; then echo Automatic boot in progress: starting file system checks. hmm... if I put /fastboot, no filesystem will be checked ? how it supposed to work for non-nfs filesystems ? is mount able to work with dirty filesystem ? what will happen if I put /fastboot and cold reset (which leaves filesystems dirty) occures ? If filesystems are dirty, they won't mount. I think /fastboot is a relic of a hundred years ago when fsck checked clean filesystems or something. The fact that /fastboot is deleted after the first boot tells me it was only supposed to be used in special cases.
Re: the idea of /fastboot ?
On Tue, Oct 09, 2012 at 22:55, ÐлÑÑ Ð¨Ð¸Ð¿Ð¸Ñин wrote: Hello! I'm investigating /etc/rc script. And I found the following there: if [ -e /fastboot ]; then echo Fast boot: skipping disk checks. elif [ X$1 = Xautoboot ]; then echo Automatic boot in progress: starting file system checks. hmm... if I put /fastboot, no filesystem will be checked ? how it supposed to work for non-nfs filesystems ? is mount able to work with dirty filesystem ? what will happen if I put /fastboot and cold reset (which leaves filesystems dirty) occures ? If filesystems are dirty, they won't mount. I think /fastboot is a relic of a hundred years ago when fsck checked clean filesystems or something. The fact that /fastboot is deleted after the first boot tells me it was only supposed to be used in special cases. Yes, it is a relic. You may take action against it, Ted.
Re: the idea of /fastboot ?
On Tue, Oct 9, 2012 at 5:01 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: Yes, it is a relic. You may take action against it, Ted. Don't forget to also remove the shutdown(8) bits that use it. Philip Guenther
Re: the idea of /fastboot ?
2012/10/10 Philip Guenther guent...@gmail.com:
On Tue, Oct 9, 2012 at 5:01 PM, Theo de Raadt dera...@cvs.openbsd.org wrote:
Yes, it is a relic. You may take action against it, Ted.
Don't forget to also remove the shutdown(8) bits that use it.
Philip Guenther
was bored, does this miss anything?
Index: rc.8
===
RCS file: /cvs/src/share/man/man8/rc.8,v
retrieving revision 1.38
diff -u -p -r1.38 rc.8
--- rc.831 Jul 2011 12:46:17 - 1.38
+++ rc.810 Oct 2012 01:18:43 -
@@ -94,11 +94,6 @@ caused by hardware or software failure.
If this auto-check and repair succeeds, then the second part of
.Nm rc
is run.
-However, if the file
-.Pa /fastboot
-exists,
-fsck will not be invoked.
-The file is then removed so that fsck will be run on subsequent boots.
.Pp
The second part of
.Nm rc
Index: pathnames.h
===
RCS file: /cvs/src/sbin/shutdown/pathnames.h,v
retrieving revision 1.5
diff -u -p -r1.5 pathnames.h
--- pathnames.h 2 Jun 2003 20:06:17 - 1.5
+++ pathnames.h 10 Oct 2012 01:18:24 -
@@ -34,7 +34,6 @@
#include paths.h
-#define_PATH_FASTBOOT /fastboot
#define_PATH_HALT /sbin/halt
#define_PATH_REBOOT/sbin/reboot
#define_PATH_WALL /usr/bin/wall
Index: shutdown.8
===
RCS file: /cvs/src/sbin/shutdown/shutdown.8,v
retrieving revision 1.39
diff -u -p -r1.39 shutdown.8
--- shutdown.8 19 Nov 2007 08:51:49 - 1.39
+++ shutdown.8 10 Oct 2012 01:18:24 -
@@ -67,16 +67,6 @@ state of a corrupted or misbehaving syst
See
.Xr savecore 8
for information on how to recover this dump.
-.It Fl f
-Create the file
-.Pa /fastboot
-so that the file systems will
-.Em not
-be checked by
-.Xr fsck 8
-during the next boot.
-(See
-.Xr rc 8 ) .
.It Fl h
The system is halted at the specified
.Ar time
Index: shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.36
diff -u -p -r1.36 shutdown.c
--- shutdown.c 24 Dec 2009 10:06:35 - 1.36
+++ shutdown.c 10 Oct 2012 01:18:24 -
@@ -56,8 +56,6 @@
#ifdef DEBUG
#undef _PATH_NOLOGIN
#define_PATH_NOLOGIN ./nologin
-#undef _PATH_FASTBOOT
-#define_PATH_FASTBOOT ./fastboot
#endif
#defineH *60*60
@@ -85,13 +83,12 @@ struct interval {
#undef S
static time_t offset, shuttime;
-static int dofast, dohalt, doreboot, dopower, dodump, mbuflen, nosync;
+static int dohalt, doreboot, dopower, dodump, mbuflen, nosync;
static sig_atomic_t killflg;
static char *whom, mbuf[BUFSIZ];
void badtime(void);
void __dead die_you_gravy_sucking_pig_dog(void);
-void doitfast(void);
void __dead finish(int);
void getoffset(char *);
void __dead loop(void);
@@ -112,7 +109,7 @@ main(int argc, char *argv[])
if (geteuid())
errx(1, NOT super-user);
#endif
- while ((ch = getopt(argc, argv, dfhknpr-)) != -1)
+ while ((ch = getopt(argc, argv, dhknpr-)) != -1)
switch (ch) {
case '-':
readstdin = 1;
@@ -120,9 +117,6 @@ main(int argc, char *argv[])
case 'd':
dodump = 1;
break;
- case 'f':
- dofast = 1;
- break;
case 'h':
dohalt = 1;
break;
@@ -147,11 +141,6 @@ main(int argc, char *argv[])
if (argc 1)
usage();
- if (dofast nosync) {
- (void)fprintf(stderr,
- shutdown: incompatible switches -f and -n.\n);
- usage();
- }
if (doreboot dohalt) {
(void)fprintf(stderr,
shutdown: incompatible switches -h and -r.\n);
@@ -340,8 +329,6 @@ die_you_gravy_sucking_pig_dog(void)
(void)printf(\rbut you'll have to do it yourself\r\n);
finish(0);
}
- if (dofast)
- doitfast();
#ifdef DEBUG
if (doreboot)
(void)printf(reboot);
@@ -349,8 +336,6 @@ die_you_gravy_sucking_pig_dog(void)
(void)printf(halt);
if (nosync)
(void)printf( no sync);
- if (dofast)
- (void)printf( no fsck);
if (dodump)
(void)printf( with dump);
(void)printf(\nkill -HUP 1\n);
@@ -489,19 +474,6 @@ getoffset(char *timearg)
}
}
-#defineFSMSG fastboot file for fsck\n
-void
-doitfast(void)
-{
- int fastfd;
-
- if ((fastfd = open(_PATH_FASTBOOT, O_WRONLY|O_CREAT|O_TRUNC,
- 0664)) = 0) {
- (void)write(fastfd, FSMSG, sizeof(FSMSG) - 1);
- (void)close(fastfd);
-
