* Nilfs features
@ 2009-05-25 9:46 Dave
[not found] ` <4A1A68E6.50905-/hCUnnzDXf0AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 8+ messages in thread
From: Dave @ 2009-05-25 9:46 UTC (permalink / raw
To: users-JrjvKiOkagjYtjvyW6yDsg
Hi,
I converted (backup/restore) my home directory onto nilfs2 to test it in
anger (yes i know the caveats about it corrupting all my data, etc, but
i'm willing to restore when required).
When restoring the data onto a nilfs2 filesystem there really is no
requirement to have the checkpointing running as you have a good copy
from your tar, cpio archive that you are restoring from. So is there a
way to temporarily suspend checkpointing with a command and then restart
it after the restore has completed ? I think this would be useful also
for when you want to have a 'privacy' mode (like firefox/mozilla) where
you can suspend checkpointing, start some confidential work, email,
browsing etc, and then restart checkpointing and roll back to the
previous state.
In addition to this there doesn't seem to be a way to delete a range of
checkpoints. When i did my restore from my archive, i generated 700+
useless checkpoints which i had to delete one by one (in a script). It
would be nice to have a 'rmcp 1-100' or 'rmcp -100' or 'rmcp 100-' to
delete a checkpoint range, a start to end.
Also it seems for home directories, a 5 second checkpointing seems
exessive. In 14hrs i have 10,000 checkpoints (even when seemingly idle
with mozilla page refreshes, dovecot index files updates for email, etc).
home:~$ uptime
13:35:09 up 14:29, 7 users, load average: 0.85, 1.76, 2.07
home:~$ lscp|tail
10342 2009-05-25 13:34:31 cp i 6698 323163
10343 2009-05-25 13:34:36 cp - 6761 323163
10344 2009-05-25 13:34:41 cp i 6702 323163
10345 2009-05-25 13:34:45 cp - 29 323163
10346 2009-05-25 13:34:46 cp i 6679 323163
10347 2009-05-25 13:34:51 cp i 6669 323163
10348 2009-05-25 13:34:56 cp i 6675 323163
10349 2009-05-25 13:35:01 cp i 6676 323163
10350 2009-05-25 13:35:06 cp i 6649 323163
10351 2009-05-25 13:35:11 cp i 6679 323163
It would also be nice to change the cp/clean interval without editing
the conf file, perhaps during the nite we can had different checkpoint
intervals and during work a smaller cp interval.
Finally instead of having 5 commands, it'd be nice to have once command
with different options (like zfs). So instead have
. nilfs checkpoint
. nilfs snapshot
. nilfs remove
. nilfs list
. nilfs suspend
. nilfs restart
etc...
All seems to be working fine so far, so take this as constructive comments.
Cheers
Dave
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Nilfs features
[not found] ` <4A1A68E6.50905-/hCUnnzDXf0AvxtiuMwx3w@public.gmane.org>
@ 2009-05-25 23:20 ` Ryusuke Konishi
[not found] ` <20090526.082051.100027806.ryusuke-sG5X7nlA6pw@public.gmane.org>
0 siblings, 1 reply; 8+ messages in thread
From: Ryusuke Konishi @ 2009-05-25 23:20 UTC (permalink / raw
To: users-JrjvKiOkagjYtjvyW6yDsg, dave-/hCUnnzDXf0AvxtiuMwx3w
Hi,
On Mon, 25 May 2009 13:46:14 +0400, Dave wrote:
> Hi,
>
> I converted (backup/restore) my home directory onto nilfs2 to test it in
> anger (yes i know the caveats about it corrupting all my data, etc, but
> i'm willing to restore when required).
What happened to you ?
Anyway, thanks for your interest in nilfs.
(yeah, I'm trying my best, but I keenly feel it's really tough to keep
the reliability of the filesystem. so, please remember the caveat.)
> When restoring the data onto a nilfs2 filesystem there really is no
> requirement to have the checkpointing running as you have a good copy
> from your tar, cpio archive that you are restoring from.
Yes, definitely.
> So is there a way to temporarily suspend checkpointing with a
> command and then restart it after the restore has completed ? I
> think this would be useful also for when you want to have a
> 'privacy' mode (like firefox/mozilla) where you can suspend
> checkpointing, start some confidential work, email, browsing etc,
> and then restart checkpointing and roll back to the previous state.
Is your demand rollback feature or some kind of silent (or invalid by
default) checkpointing, or both ?
The checkpointing is essential for nilfs, every write on nilfs
requires creating a checkpoint by its nature. But I think it's
possible to make them inaccessible by default.
Rollback is worth considering. Yes, I agree. it actually makes the
recovery of filesystem state smarter.
It even could be a first step toward realization of the remote
replication (as discussed before in this mailing list).
> In addition to this there doesn't seem to be a way to delete a range of
> checkpoints. When i did my restore from my archive, i generated 700+
> useless checkpoints which i had to delete one by one (in a script). It
> would be nice to have a 'rmcp 1-100' or 'rmcp -100' or 'rmcp 100-' to
> delete a checkpoint range, a start to end.
Okay, I'll take in this in some form.
> Also it seems for home directories, a 5 second checkpointing seems
> exessive. In 14hrs i have 10,000 checkpoints (even when seemingly idle
> with mozilla page refreshes, dovecot index files updates for email, etc).
>
> home:~$ uptime
> 13:35:09 up 14:29, 7 users, load average: 0.85, 1.76, 2.07
> home:~$ lscp|tail
> 10342 2009-05-25 13:34:31 cp i 6698 323163
> 10343 2009-05-25 13:34:36 cp - 6761 323163
> 10344 2009-05-25 13:34:41 cp i 6702 323163
> 10345 2009-05-25 13:34:45 cp - 29 323163
> 10346 2009-05-25 13:34:46 cp i 6679 323163
> 10347 2009-05-25 13:34:51 cp i 6669 323163
> 10348 2009-05-25 13:34:56 cp i 6675 323163
> 10349 2009-05-25 13:35:01 cp i 6676 323163
> 10350 2009-05-25 13:35:06 cp i 6649 323163
> 10351 2009-05-25 13:35:11 cp i 6679 323163
>
>
> It would also be nice to change the cp/clean interval without editing
> the conf file, perhaps during the nite we can had different checkpoint
> intervals and during work a smaller cp interval.
Checkpoint creation is essential to nilfs writes, so this seems to be
difficult without introducing some kind of invisible checkpoint.
(checkpoint removal is much easier, but I understood what you want
slightly differs from such external )
I think it needs care because the feature partially invalidate what
the nilfs stands for. Maybe 5 seconds checkpoining should be remained
as default. But some flexiblity might well be allowed as you pointed
out.
Supporting method changing cleaning interval without editing the conf
file, sounds reasonable (yes, sorry for inconvenience).
> Finally instead of having 5 commands, it'd be nice to have once command
> with different options (like zfs). So instead have
>
> . nilfs checkpoint
> . nilfs snapshot
> . nilfs remove
> . nilfs list
> . nilfs suspend
> . nilfs restart
> etc...
Yeah, I agree reorganizing commands into one 'nilfs' command is
preferable. Well, I'll add this to the todo items on the site.
I think it would be nice if the old commands are available through
symbolic links to this unified command according to user's
predilection.
> All seems to be working fine so far, so take this as constructive comments.
>
> Cheers
> Dave
Thank you for many productive comments!
Regards,
Ryusuke Konishi
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Nilfs features
[not found] ` <20090526.082051.100027806.ryusuke-sG5X7nlA6pw@public.gmane.org>
@ 2009-05-26 4:54 ` Dave
2009-05-31 16:20 ` Ryusuke Konishi
1 sibling, 0 replies; 8+ messages in thread
From: Dave @ 2009-05-26 4:54 UTC (permalink / raw
To: NILFS Users mailing list, ryusuke-sG5X7nlA6pw
Ryusuke Konishi wrote:
>
>> I converted (backup/restore) my home directory onto nilfs2 to test it in
>> anger (yes i know the caveats about it corrupting all my data, etc, but
>> i'm willing to restore when required).
>
> What happened to you ?
> Anyway, thanks for your interest in nilfs.
> (yeah, I'm trying my best, but I keenly feel it's really tough to keep
> the reliability of the filesystem. so, please remember the caveat.)
Yes, understood very well, but you also you underestimate your code ;-)
Please keep up the good work. The free world has been waiting for this
kind of filesystem for a while.
>> So is there a way to temporarily suspend checkpointing with a
>> command and then restart it after the restore has completed ? I
>> think this would be useful also for when you want to have a
>> 'privacy' mode (like firefox/mozilla) where you can suspend
>> checkpointing, start some confidential work, email, browsing etc,
>> and then restart checkpointing and roll back to the previous state.
>
> Is your demand rollback feature or some kind of silent (or invalid by
> default) checkpointing, or both ?
No, not demanding anything. Requesting it as a feature. While your
design has a very crucial use-case of constant checkpointing, there is
also a use-case to *suspend* checkpointing (or enable it on demand
only). As mentioned in my previous example, when restoring to a
filesystem, or even installing new software, it is extremely unlikely
that you would want a to go back to a point *inbetween* the time you
started the install/restore to the time it completed. Say for example
you are installing a new version of Openoffice which installs
home:/opt/openoffice.org$ find . ! -type d |wc -l
4100
4000 odd files. For sure if the software didn't work, crashed, was
buggy, i would go back completely to the pre-install state and would
never need any intervening checkpoint. In this case i would suspend
checkpointing before installing (which may by default create a
snapshot), and then i'd restart the constant checkpointing after i'd
finished the install/restore. Please note, i am not comparing nilfs to
zfs, but zfs doesn't have constant cp (i think) but does have the
feature i mention, i.e you take snapshots when needed (perhaps via a
cron job daily, monthly, weekly)
> The checkpointing is essential for nilfs, every write on nilfs
> requires creating a checkpoint by its nature. But I think it's
> possible to make them inaccessible by default.
>
> Rollback is worth considering. Yes, I agree. it actually makes the
> recovery of filesystem state smarter.
>
> It even could be a first step toward realization of the remote
> replication (as discussed before in this mailing list).
Yes, after i posted, i went back on the mailing list and seen the
request already. Sorry for requesting the feature again.
> I think it needs care because the feature partially invalidate what
> the nilfs stands for. Maybe 5 seconds checkpoining should be remained
> as default. But some flexiblity might well be allowed as you pointed
> out.
Agreed, but it wouldn't invalidate what nilfs stood for, it would
enhance it, but it is your code, so it's your right to decide and i
respect that.
> Supporting method changing cleaning interval without editing the conf
> file, sounds reasonable (yes, sorry for inconvenience).
No need to apologize.
>> Finally instead of having 5 commands, it'd be nice to have once command
>> with different options (like zfs). So instead have
>>
>> . nilfs checkpoint
>> . nilfs snapshot
>> . nilfs remove
>> . nilfs list
>> . nilfs suspend
>> . nilfs restart
>> etc...
>
> Yeah, I agree reorganizing commands into one 'nilfs' command is
> preferable. Well, I'll add this to the todo items on the site.
Thanks (my /usr/bin directory seems to be growing exponentially).
> I think it would be nice if the old commands are available through
> symbolic links to this unified command according to user's
> predilection.
Agreed, but why have 5 commands and 5 manpages when you can have 1 of
each ;-). I think users will get used to it and eventually you can
delete the symlinks.
Thanks for your responses.
D
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Nilfs features
@ 2009-05-30 3:44 Jérôme Poulin
[not found] ` <debc30fc0905292044r311a2842j53832195d0ef88bd-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 8+ messages in thread
From: Jérôme Poulin @ 2009-05-30 3:44 UTC (permalink / raw
To: users-JrjvKiOkagjYtjvyW6yDsg
[-- Attachment #1.1: Type: text/plain, Size: 1730 bytes --]
>
> No, not demanding anything. Requesting it as a feature. While your
> design has a very crucial use-case of constant checkpointing, there is
>
> also a use-case to *suspend* checkpointing (or enable it on demand
> only). As mentioned in my previous example, when restoring to a
> filesystem, or even installing new software, it is extremely unlikely
> that you would want a to go back to a point *inbetween* the time you
>
> started the install/restore to the time it completed. Say for example
> you are installing a new version of Openoffice which installs
>
> home:/opt/openoffice.org$ find . ! -type d |wc -l
>
> 4100
>
> 4000 odd files. For sure if the software didn't work, crashed, was
> buggy, i would go back completely to the pre-install state and would
> never need any intervening checkpoint. In this case i would suspend
>
> checkpointing before installing (which may by default create a
> snapshot), and then i'd restart the constant checkpointing after i'd
> finished the install/restore. Please note, i am not comparing nilfs to
> zfs, but zfs doesn't have constant cp (i think) but does have the
>
> feature i mention, i.e you take snapshots when needed (perhaps via a
> cron job daily, monthly, weekly)
>
> I just want to give my though on this one, keeping checkpoints as-is seems
ideal to me, in this case you have a very granular way to go back in time,
however, what you say is right, when installing a new software for example,
it's nice to have a way to get back to it, I guess in this case you would
just convert the last checkpoint to snapshot before the installation so you
have a time mark of where to rollback (and of course have a steady state
which won't go away during the installation), right?
[-- Attachment #1.2: Type: text/html, Size: 1987 bytes --]
[-- Attachment #2: Type: text/plain, Size: 158 bytes --]
_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Nilfs features
[not found] ` <20090526.082051.100027806.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-05-26 4:54 ` Dave
@ 2009-05-31 16:20 ` Ryusuke Konishi
[not found] ` <20090601.012057.21016829.ryusuke-sG5X7nlA6pw@public.gmane.org>
1 sibling, 1 reply; 8+ messages in thread
From: Ryusuke Konishi @ 2009-05-31 16:20 UTC (permalink / raw
To: users-JrjvKiOkagjYtjvyW6yDsg, dave-/hCUnnzDXf0AvxtiuMwx3w
Cc: Jérôme Poulin
Hi,
On Tue, 26 May 2009 08:20:51 +0900 (JST), Ryusuke Konishi wrote:
> Hi,
> On Mon, 25 May 2009 13:46:14 +0400, Dave wrote:
> > In addition to this there doesn't seem to be a way to delete a range of
> > checkpoints. When i did my restore from my archive, i generated 700+
> > useless checkpoints which i had to delete one by one (in a script). It
> > would be nice to have a 'rmcp 1-100' or 'rmcp -100' or 'rmcp 100-' to
> > delete a checkpoint range, a start to end.
>
> Okay, I'll take in this in some form.
For the moment, I've added this feature and pushed it into the git
tree.
(Instead of '1-100', '-100', or '10..', I took notation like '1..100',
'..100', or '10..' respectively, according to the git tool)
If you would like to try it soon, please see
http://www.nilfs.org/git/
for download/build information.
I'll include it in the next release of the utility package.
Cheers,
Ryusuke Konishi
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Nilfs features
[not found] ` <20090601.012057.21016829.ryusuke-sG5X7nlA6pw@public.gmane.org>
@ 2009-06-02 8:21 ` Dave
[not found] ` <4A24E100.8040204-/hCUnnzDXf0AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 8+ messages in thread
From: Dave @ 2009-06-02 8:21 UTC (permalink / raw
To: NILFS Users mailing list, ryusuke-sG5X7nlA6pw
On 05/31/09 20:20, Ryusuke Konishi wrote:
> Hi,
> On Tue, 26 May 2009 08:20:51 +0900 (JST), Ryusuke Konishi wrote:
>> Hi,
>> On Mon, 25 May 2009 13:46:14 +0400, Dave wrote:
>>> In addition to this there doesn't seem to be a way to delete a range of
>>> checkpoints. When i did my restore from my archive, i generated 700+
>>> useless checkpoints which i had to delete one by one (in a script). It
>>> would be nice to have a 'rmcp 1-100' or 'rmcp -100' or 'rmcp 100-' to
>>> delete a checkpoint range, a start to end.
>> Okay, I'll take in this in some form.
>
> For the moment, I've added this feature and pushed it into the git
> tree.
>
> (Instead of '1-100', '-100', or '10..', I took notation like '1..100',
> '..100', or '10..' respectively, according to the git tool)
>
> If you would like to try it soon, please see
>
> http://www.nilfs.org/git/
>
> for download/build information.
>
> I'll include it in the next release of the utility package.
>
Hi Ryusuke,
I've tried this and it seems to work perfectly. Thanks for the quick
feature addition.
It seems that i still have to wait for cleanerd to kick in to reclaim
the space even though i clearly cannot get to a checkpoint i've just
deleted. I believe we should reclaim immediately (but perhaps this is
harder to implement)...
bash-3.2# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 39G 9.0G 28G 25% /home
bash-3.2# cp /shared/1gb .
bash-3.2# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 39G 10G 27G 28% /home
bash-3.2# lscp | tail
155133 2009-06-02 12:12:27 cp i 6662 253255
155134 2009-06-02 12:12:29 cp - 35 253255
155135 2009-06-02 12:12:32 cp i 6622 253255
155136 2009-06-02 12:12:37 cp i 6587 253255
155137 2009-06-02 12:12:42 cp i 6654 253255
155138 2009-06-02 12:12:47 cp i 6744 253255
155139 2009-06-02 12:12:52 cp i 6524 253255
155140 2009-06-02 12:12:57 cp i 6762 253255
155141 2009-06-02 12:13:02 cp i 6670 253255
155142 2009-06-02 12:13:07 cp - 6748 253255
bash-3.2# rm 1gb
bash-3.2# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 39G 10G 27G 28% /home
bash-3.2# lscp|tail
155151 2009-06-02 12:13:29 cp - 35 253188
155152 2009-06-02 12:13:35 cp - 237 253229
155153 2009-06-02 12:13:37 cp - 6334 253238
155154 2009-06-02 12:13:42 cp - 8380 253255
155155 2009-06-02 12:13:47 cp i 7987 253255
155156 2009-06-02 12:13:52 cp i 3743 253255
155157 2009-06-02 12:13:57 cp i 8092 253255
155158 2009-06-02 12:14:02 cp i 7991 253255
155159 2009-06-02 12:14:07 cp i 7986 253255
155160 2009-06-02 12:14:12 cp - 9129 253254
bash-3.2# rmcp ..155160
bash-3.2# lscp|tail
CNO DATE TIME MODE FLG NBLKINC ICNT
155161 2009-06-02 12:14:17 cp i 6839 253254
155162 2009-06-02 12:14:22 cp i 7012 253254
155163 2009-06-02 12:14:27 cp - 6886 253255
155164 2009-06-02 12:14:29 cp - 51 253254
155165 2009-06-02 12:14:32 cp i 6737 253254
155166 2009-06-02 12:14:37 cp i 2618 253254
bash-3.2# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 39G 10G 27G 28% /home
much appreciated.
Dave
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Nilfs features
[not found] ` <debc30fc0905292044r311a2842j53832195d0ef88bd-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2009-06-02 8:31 ` Dave
0 siblings, 0 replies; 8+ messages in thread
From: Dave @ 2009-06-02 8:31 UTC (permalink / raw
To: NILFS Users mailing list, jeromepoulin-Re5JQEeQqe8AvxtiuMwx3w
On 05/30/09 07:44, Jérôme Poulin wrote:
> checkpointing before installing (which may by default create a
> snapshot), and then i'd restart the constant checkpointing after i'd
> finished the install/restore. Please note, i am not comparing nilfs to
>
> zfs, but zfs doesn't have constant cp (i think) but does have the
>
> feature i mention, i.e you take snapshots when needed (perhaps via a
> cron job daily, monthly, weekly)
>
> I just want to give my though on this one, keeping checkpoints as-is
> seems ideal to me, in this case you have a very granular way to go back
> in time, however, what you say is right, when installing a new software
> for example, it's nice to have a way to get back to it, I guess in this
> case you would just convert the last checkpoint to snapshot before the
> installation so you have a time mark of where to rollback (and of course
> have a steady state which won't go away during the installation), right?
Yes correct. Imagine you're installing a fresh OS on a nilfs formatted
disk. You'd have 1000+ interemediate checkpoints which would be of no
use. Temporary suspension until the OS is installed is a real life
use-case. Your filesystem is in 2 states, either no OS or a full OS state.
Cheers
D
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Nilfs features
[not found] ` <4A24E100.8040204-/hCUnnzDXf0AvxtiuMwx3w@public.gmane.org>
@ 2009-06-02 9:23 ` Ryusuke Konishi
0 siblings, 0 replies; 8+ messages in thread
From: Ryusuke Konishi @ 2009-06-02 9:23 UTC (permalink / raw
To: dave-/hCUnnzDXf0AvxtiuMwx3w; +Cc: users-JrjvKiOkagjYtjvyW6yDsg
Hi,
On Tue, 02 Jun 2009 12:21:20 +0400, Dave wrote:
> On 05/31/09 20:20, Ryusuke Konishi wrote:
> > Hi,
> > On Tue, 26 May 2009 08:20:51 +0900 (JST), Ryusuke Konishi wrote:
> >> Hi,
> >> On Mon, 25 May 2009 13:46:14 +0400, Dave wrote:
> >>> In addition to this there doesn't seem to be a way to delete a range of
> >>> checkpoints. When i did my restore from my archive, i generated 700+
> >>> useless checkpoints which i had to delete one by one (in a script). It
> >>> would be nice to have a 'rmcp 1-100' or 'rmcp -100' or 'rmcp 100-' to
> >>> delete a checkpoint range, a start to end.
> >> Okay, I'll take in this in some form.
> >
> > For the moment, I've added this feature and pushed it into the git
> > tree.
> >
> > (Instead of '1-100', '-100', or '10..', I took notation like '1..100',
> > '..100', or '10..' respectively, according to the git tool)
> >
> > If you would like to try it soon, please see
> >
> > http://www.nilfs.org/git/
> >
> > for download/build information.
> >
> > I'll include it in the next release of the utility package.
> >
>
> Hi Ryusuke,
>
> I've tried this and it seems to work perfectly. Thanks for the quick
> feature addition.
>
> It seems that i still have to wait for cleanerd to kick in to reclaim
> the space even though i clearly cannot get to a checkpoint i've just
> deleted. I believe we should reclaim immediately (but perhaps this is
> harder to implement)...
Yes, checkpoint removal by rmcp does not mean reclamation; operation
of the cleanerd is necessary to that end.
Well, I thought the (plain) checkpoints are equivalent to deleted
ones. But the checkpoint removal makes a differece in that deleted
checkpoints become unprotected by the protection period.
Hmm, indeed we need some change on the cleanerd.
At least the cleanerd should be notified about the removal and
revaluate the need of reclamation.
Thanks you for feedback.
Regards,
Ryusuke Konishi
> bash-3.2# df -h .
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdb2 39G 9.0G 28G 25% /home
> bash-3.2# cp /shared/1gb .
> bash-3.2# df -h .
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdb2 39G 10G 27G 28% /home
> bash-3.2# lscp | tail
> 155133 2009-06-02 12:12:27 cp i 6662 253255
> 155134 2009-06-02 12:12:29 cp - 35 253255
> 155135 2009-06-02 12:12:32 cp i 6622 253255
> 155136 2009-06-02 12:12:37 cp i 6587 253255
> 155137 2009-06-02 12:12:42 cp i 6654 253255
> 155138 2009-06-02 12:12:47 cp i 6744 253255
> 155139 2009-06-02 12:12:52 cp i 6524 253255
> 155140 2009-06-02 12:12:57 cp i 6762 253255
> 155141 2009-06-02 12:13:02 cp i 6670 253255
> 155142 2009-06-02 12:13:07 cp - 6748 253255
> bash-3.2# rm 1gb
> bash-3.2# df -h .
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdb2 39G 10G 27G 28% /home
> bash-3.2# lscp|tail
> 155151 2009-06-02 12:13:29 cp - 35 253188
> 155152 2009-06-02 12:13:35 cp - 237 253229
> 155153 2009-06-02 12:13:37 cp - 6334 253238
> 155154 2009-06-02 12:13:42 cp - 8380 253255
> 155155 2009-06-02 12:13:47 cp i 7987 253255
> 155156 2009-06-02 12:13:52 cp i 3743 253255
> 155157 2009-06-02 12:13:57 cp i 8092 253255
> 155158 2009-06-02 12:14:02 cp i 7991 253255
> 155159 2009-06-02 12:14:07 cp i 7986 253255
> 155160 2009-06-02 12:14:12 cp - 9129 253254
> bash-3.2# rmcp ..155160
> bash-3.2# lscp|tail
> CNO DATE TIME MODE FLG NBLKINC ICNT
> 155161 2009-06-02 12:14:17 cp i 6839 253254
> 155162 2009-06-02 12:14:22 cp i 7012 253254
> 155163 2009-06-02 12:14:27 cp - 6886 253255
> 155164 2009-06-02 12:14:29 cp - 51 253254
> 155165 2009-06-02 12:14:32 cp i 6737 253254
> 155166 2009-06-02 12:14:37 cp i 2618 253254
> bash-3.2# df -h .
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdb2 39G 10G 27G 28% /home
>
>
>
> much appreciated.
> Dave
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-06-02 9:23 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-25 9:46 Nilfs features Dave
[not found] ` <4A1A68E6.50905-/hCUnnzDXf0AvxtiuMwx3w@public.gmane.org>
2009-05-25 23:20 ` Ryusuke Konishi
[not found] ` <20090526.082051.100027806.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-05-26 4:54 ` Dave
2009-05-31 16:20 ` Ryusuke Konishi
[not found] ` <20090601.012057.21016829.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-02 8:21 ` Dave
[not found] ` <4A24E100.8040204-/hCUnnzDXf0AvxtiuMwx3w@public.gmane.org>
2009-06-02 9:23 ` Ryusuke Konishi
-- strict thread matches above, loose matches on Subject: below --
2009-05-30 3:44 Jérôme Poulin
[not found] ` <debc30fc0905292044r311a2842j53832195d0ef88bd-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-02 8:31 ` Dave
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.