Is this stupid?

Is this stupid?

[Leslie Rhorer]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

I have a system - one that is not expandable - that has relatively limited
RAM, comparatively speaking, and must boot from a usb stick.  The system
hosts a RAID array, but one cannot assume the RAID array is available when
the system boots.  IOW, I want to be able to take down the RAID array for
maintenance, possibly booting the system with no array created, at all.

On the other hand, USB sticks have a limited number of writes available
before they fail, so I don't want the system to be thrashing the flash drive
any more than necessary.  At this time,  I have /var/run, /var/log,
/var/lock, and /tmp mounted as tmpfs file systems.  What I propose is to run
an init script that checks to see if the array is mounted, and if so appends
files in the aforementioned directories to existing directories on the array
and then remounts and binds the directories on the array.  The stop call in
the script will reverse the process so the system can shutdown or so I can
take the array offline after booting for maintenance.  Is this unwise?  Am I
missing something crucial that might cause the system to blow up?

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3358 bytes --]

Re: Is this stupid?

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

On Sun, 4 Dec 2011 16:28:25 -0600 "Leslie Rhorer" <lrhorer@satx.rr.com> wrote:

> I have a system - one that is not expandable - that has relatively limited
> RAM, comparatively speaking, and must boot from a usb stick.  The system
> hosts a RAID array, but one cannot assume the RAID array is available when
> the system boots.  IOW, I want to be able to take down the RAID array for
> maintenance, possibly booting the system with no array created, at all.
> 
> On the other hand, USB sticks have a limited number of writes available
> before they fail, so I don't want the system to be thrashing the flash drive
> any more than necessary.  At this time,  I have /var/run, /var/log,
> /var/lock, and /tmp mounted as tmpfs file systems.  What I propose is to run
> an init script that checks to see if the array is mounted, and if so appends
> files in the aforementioned directories to existing directories on the array
> and then remounts and binds the directories on the array.  The stop call in
> the script will reverse the process so the system can shutdown or so I can
> take the array offline after booting for maintenance.  Is this unwise?  Am I
> missing something crucial that might cause the system to blow up?

Sounds reasonably sane.

After the bind mount you would need to make sure any process with a file
open in one of those directories re-opens the file.  So you might want to
restart syslogd.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

RE: Is this stupid?

[Leslie Rhorer]

> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Monday, December 05, 2011 12:01 AM
> To: Leslie Rhorer
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Is this stupid?
> 
> On Sun, 4 Dec 2011 16:28:25 -0600 "Leslie Rhorer" <lrhorer@satx.rr.com>
> wrote:
> 
> > I have a system - one that is not expandable - that has relatively
> limited
> > RAM, comparatively speaking, and must boot from a usb stick.  The system
> > hosts a RAID array, but one cannot assume the RAID array is available
> when
> > the system boots.  IOW, I want to be able to take down the RAID array
> for
> > maintenance, possibly booting the system with no array created, at all.
> >
> > On the other hand, USB sticks have a limited number of writes available
> > before they fail, so I don't want the system to be thrashing the flash
> drive
> > any more than necessary.  At this time,  I have /var/run, /var/log,
> > /var/lock, and /tmp mounted as tmpfs file systems.  What I propose is to
> run
> > an init script that checks to see if the array is mounted, and if so
> appends
> > files in the aforementioned directories to existing directories on the
> array
> > and then remounts and binds the directories on the array.  The stop call
> in
> > the script will reverse the process so the system can shutdown or so I
> can
> > take the array offline after booting for maintenance.  Is this unwise?
> Am I
> > missing something crucial that might cause the system to blow up?
> 
> Sounds reasonably sane.
> 
> After the bind mount you would need to make sure any process with a file
> open in one of those directories re-opens the file.  So you might want to
> restart syslogd.

Yeah, I was intending to do that, along with any other processes that
require it.  'Basically do the same thing that logrotate does.

Re: Is this stupid?

[Doug Dumitru]

Mr. Rhorer,

Don't work too hard over-thinking this in terms of wearing the stick
out.  Current USB sticks are built with dirt cheap, often three bits
per cell flash with lousy endurance and minimal wear leveling.  Even
so, if you have an 8GB stick that writes at 5 MB/sec and 600
endurance, it still takes 11 days of 100% busy writes to kill it.

The real issue with booting from a USB stick (and the same rules apply
to CF cards), is that some operations like syslogd sync writes can
take forever and then some.

One other trick is to either use a more "flash friendly" file system,
or at least turn off atime tracking.

Doug Dumitru
EasyCo LLC

On Sun, Dec 4, 2011 at 2:28 PM, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
> I have a system - one that is not expandable - that has relatively limited
> RAM, comparatively speaking, and must boot from a usb stick.  The system
> hosts a RAID array, but one cannot assume the RAID array is available when
> the system boots.  IOW, I want to be able to take down the RAID array for
> maintenance, possibly booting the system with no array created, at all.
>
> On the other hand, USB sticks have a limited number of writes available
> before they fail, so I don't want the system to be thrashing the flash drive
> any more than necessary.  At this time,  I have /var/run, /var/log,
> /var/lock, and /tmp mounted as tmpfs file systems.  What I propose is to run
> an init script that checks to see if the array is mounted, and if so appends
> files in the aforementioned directories to existing directories on the array
> and then remounts and binds the directories on the array.  The stop call in
> the script will reverse the process so the system can shutdown or so I can
> take the array offline after booting for maintenance.  Is this unwise?  Am I
> missing something crucial that might cause the system to blow up?



-- 
Doug Dumitru
EasyCo LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Is this stupid?

[Leslie Rhorer]

> -----Original Message-----
> From: dougdumitruredirect@gmail.com [mailto:dougdumitruredirect@gmail.com]
> On Behalf Of Doug Dumitru
> Sent: Monday, December 05, 2011 12:18 AM
> To: Leslie Rhorer
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Is this stupid?
> 
> Mr. Rhorer,
> 
> Don't work too hard over-thinking this in terms of wearing the stick
> out.  Current USB sticks are built with dirt cheap, often three bits
> per cell flash with lousy endurance and minimal wear leveling.  Even
> so, if you have an 8GB stick that writes at 5 MB/sec and 600
> endurance, it still takes 11 days of 100% busy writes to kill it.

I'm thinking more like 3 years or so.

> The real issue with booting from a USB stick (and the same rules apply
> to CF cards), is that some operations like syslogd sync writes can
> take forever and then some.

Yeah, that seems to be the main concern, along with the fact there is more
than one asynchronous process doing the writing.

> One other trick is to either use a more "flash friendly" file system,

Such as?  Of course both tmpfs and the hard drive are both 100% flash
friendly, which is the point.

> or at least turn off atime tracking.

Yeah, I've done that.  The writes to /var/log, /var/run, /var/lock, and /tmp
are 100% flash friendly at the moment.  They just aren't RAM friendly.  Of
course, with 512M of real memory and 512M of RAID array based swap, maybe
I'm just being a mother hen.  At the moment, only 71M of RAM is in use, and
none on the RAID array.  With the Ethernet interfaces set to use static IPs,
rsyslog is hardly putting out anything at all.  I have logrotate running
every hour, and all the logs limited to rather small sizes.  The biggest
offender is SAMBA, who has over 500K of files open in /var/run.