|
|
|
|
|
|
| Author |
Message |
Ollivier Robert
*nix forums beginner
Joined: 21 Mar 2002
Posts: 19
|
 Posted: Wed Mar 27, 2002 9:19 am Post subject:
[PATCH] MFC the full filesystem softupdates fix ?
|
|
|
Following some discussions in the French fr.comp.os.bsd newsgroup about
softupdates and the full filesystem problem (which is fixed in CURRENT
thanks to you), here a proposed diff to merge the fix into STABLE.
Can you (and -arch) review it ? It would be nice to have this fixed in
STABLE as well.
Thanks.
Index: ffs_alloc.c
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_alloc.c,v
retrieving revision 1.64.2.2
diff -u -2 -r1.64.2.2 ffs_alloc.c
--- ffs_alloc.c 21 Sep 2001 19:15:21 -0000 1.64.2.2
+++ ffs_alloc.c 27 Mar 2002 10:08:29 -0000
@@ -107,5 +107,5 @@
register struct fs *fs;
ufs_daddr_t bno;
- int cg;
+ int cg, reclaimed;
#ifdef QUOTA
int error;
@@ -124,4 +124,6 @@
panic("ffs_alloc: missing credential");
#endif /* DIAGNOSTIC */
+ reclaimed = 0;
+retry:
if (size == fs->fs_bsize && fs->fs_cstotal.cs_nbfree == 0)
goto nospace;
@@ -155,4 +157,9 @@
#endif
nospace:
+ if (fs->fs_pendingblocks > 0 && reclaimed == 0) {
+ reclaimed = 1;
+ softdep_request_cleanup(fs, ITOV(ip));
+ goto retry;
+ }
ffs_fserr(fs, cred->cr_uid, "file system full");
uprintf("\n%s: write failed, file system is full\n", fs->fs_fsmnt);
@@ -177,7 +184,7 @@
struct buf **bpp;
{
- register struct fs *fs;
+ struct fs *fs;
struct buf *bp;
- int cg, request, error;
+ int cg, request, error, reclaimed;
ufs_daddr_t bprev, bno;
@@ -198,4 +205,6 @@
if (cred->cr_uid != 0 &&
freespace(fs, fs->fs_minfree) - numfrags(fs, nsize - osize) < 0)
+ reclaimed = 0;
+retry:
goto nospace;
if ((bprev = ip->i_db[lbprev]) == 0) {
@@ -208,5 +217,5 @@
* Allocate the extra space in the buffer.
*/
- error = bread(ITOV(ip), lbprev, osize, NOCRED, &bp);
+ error = bread(vp, lbprev, osize, NOCRED, &bp);
if (error) {
brelse(bp);
@@ -295,5 +304,5 @@
if (bno > 0) {
bp->b_blkno = fsbtodb(fs, bno);
- if (!DOINGSOFTDEP(ITOV(ip)))
+ if (!DOINGSOFTDEP(vp))
ffs_blkfree(ip, bprev, (long)osize);
if (nsize < request)
@@ -319,4 +328,9 @@
* no space available
*/
+ if (fs->fs_pendingblocks > 0 && reclaimed == 0) {
+ reclaimed = 1;
+ softdep_request_cleanup(fs, vp);
+ goto retry;
+ }
ffs_fserr(fs, cred->cr_uid, "file system full");
uprintf("\n%s: write failed, file system is full\n", fs->fs_fsmnt);
Index: ffs_extern.h
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_extern.h,v
retrieving revision 1.30
diff -u -2 -r1.30 ffs_extern.h
--- ffs_extern.h 9 Jan 2000 22:40:02 -0000 1.30
+++ ffs_extern.h 27 Mar 2002 10:05:03 -0000
@@ -115,4 +115,5 @@
void softdep_load_inodeblock __P((struct inode *));
void softdep_freefile __P((struct vnode *, ino_t, int));
+int softdep_request_cleanup __P((struct fs *, struct vnode *));
void softdep_setup_freeblocks __P((struct inode *, off_t));
void softdep_setup_inomapdep __P((struct buf *, struct inode *, ino_t));
Index: ffs_softdep.c
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v
retrieving revision 1.57.2.11
diff -u -2 -r1.57.2.11 ffs_softdep.c
--- ffs_softdep.c 5 Feb 2002 18:46:53 -0000 1.57.2.11
+++ ffs_softdep.c 27 Mar 2002 10:12:48 -0000
@@ -508,7 +508,8 @@
static struct proc *filesys_syncer; /* proc of filesystem syncer process */
static int req_clear_inodedeps; /* syncer process flush some inodedeps */
-#define FLUSH_INODES 1
+#define FLUSH_INODES 1
static int req_clear_remove; /* syncer process flush some freeblks */
-#define FLUSH_REMOVE 2
+#define FLUSH_REMOVE 2
+#define FLUSH_REMOVE_WAIT 3
/*
* runtime statistics
@@ -703,5 +704,5 @@
if (wk == 0) {
FREE_LOCK(&lk);
- return (0);
+ return (-1);
}
WORKLIST_REMOVE(wk);
@@ -4561,4 +4562,39 @@
/*
+ * Called by the allocation routines when they are about to fail
+ * in the hope that we can free up some disk space.
+ *
+ * First check to see if the work list has anything on it. If it has,
+ * clean up entries until we successfully free some space. Because this
+ * process holds inodes locked, we cannot handle any remove requests
+ * that might block on a locked inode as that could lead to deadlock.
+ * If the worklist yields no free space, encourage the syncer daemon
+ * to help us. In no event will we try for longer than tickdelay seconds.
+ */
+int
+softdep_request_cleanup(fs, vp)
+ struct fs *fs;
+ struct vnode *vp;
+{
+ long starttime, needed;
+
+ needed = fs->fs_cstotal.cs_nbfree + fs->fs_contigsumsize;
+ starttime = time_second + tickdelay;
+ if (UFS_UPDATE(vp, 1) != 0)
+ return (0);
+ while (fs->fs_pendingblocks > 0 && fs->fs_cstotal.cs_nbfree <= needed) {
+ if (time_second > starttime)
+ return (0);
+ if (num_on_worklist > 0 &&
+ process_worklist_item(NULL, LK_NOWAIT) != -1) {
+ stat_worklist_push += 1;
+ continue;
+ }
+ request_cleanup(FLUSH_REMOVE_WAIT, 0);
+ }
+ return (1);
+}
+
+/*
* If memory utilization has gotten too high, deliberately slow things
* down and speed up the I/O processing.
@@ -4595,4 +4631,10 @@
/*
+ * Next, we attempt to speed up the syncer process. If that
+ * is successful, then we allow the process to continue.
+ */
+ if (speedup_syncer() && resource != FLUSH_REMOVE_WAIT)
+ return(0);
+ /*
* If we are resource constrained on inode dependencies, try
* flushing some dirty inodes. Otherwise, we are constrained
@@ -4613,4 +4655,5 @@
case FLUSH_REMOVE:
+ case FLUSH_REMOVE_WAIT:
stat_blk_limit_push += 1;
req_clear_remove += 1;
--
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr
FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Kirk McKusick
*nix forums beginner
Joined: 19 Mar 2002
Posts: 40
|
| Posted: Wed Mar 27, 2002 8:34 pm Post subject:
Re: [PATCH] MFC the full filesystem softupdates fix ?
|
|
|
If it was easy as your patch, there would be no problem in
putting it in. The problem is that -current does not have
the code to maintain the fs_pendingblocks variable. At a
minimum you would have to add that code as well. It is a
good deal more extensive, though at this point well enough
tested that I am less fearful of adding it.
Kirk McKusick
=-=-=-=-=-=
Date: Wed, 27 Mar 2002 11:19:47 +0100
From: Ollivier Robert <roberto@eurocontrol.fr>
To: mckusick@mckusick.com
Cc: arch@FreeBSD.ORG
Subject: [PATCH] MFC the full filesystem softupdates fix ?
Following some discussions in the French fr.comp.os.bsd newsgroup about
softupdates and the full filesystem problem (which is fixed in CURRENT
thanks to you), here a proposed diff to merge the fix into STABLE.
Can you (and -arch) review it ? It would be nice to have this fixed in
STABLE as well.
Thanks.
Index: ffs_alloc.c
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_alloc.c,v
retrieving revision 1.64.2.2
diff -u -2 -r1.64.2.2 ffs_alloc.c
--- ffs_alloc.c 21 Sep 2001 19:15:21 -0000 1.64.2.2
+++ ffs_alloc.c 27 Mar 2002 10:08:29 -0000
@@ -107,5 +107,5 @@
register struct fs *fs;
ufs_daddr_t bno;
- int cg;
+ int cg, reclaimed;
#ifdef QUOTA
int error;
@@ -124,4 +124,6 @@
panic("ffs_alloc: missing credential");
#endif /* DIAGNOSTIC */
+ reclaimed = 0;
+retry:
if (size == fs->fs_bsize && fs->fs_cstotal.cs_nbfree == 0)
goto nospace;
@@ -155,4 +157,9 @@
#endif
nospace:
+ if (fs->fs_pendingblocks > 0 && reclaimed == 0) {
+ reclaimed = 1;
+ softdep_request_cleanup(fs, ITOV(ip));
+ goto retry;
+ }
ffs_fserr(fs, cred->cr_uid, "file system full");
uprintf("\n%s: write failed, file system is full\n", fs->fs_fsmnt);
@@ -177,7 +184,7 @@
struct buf **bpp;
{
- register struct fs *fs;
+ struct fs *fs;
struct buf *bp;
- int cg, request, error;
+ int cg, request, error, reclaimed;
ufs_daddr_t bprev, bno;
@@ -198,4 +205,6 @@
if (cred->cr_uid != 0 &&
freespace(fs, fs->fs_minfree) - numfrags(fs, nsize - osize) < 0)
+ reclaimed = 0;
+retry:
goto nospace;
if ((bprev = ip->i_db[lbprev]) == 0) {
@@ -208,5 +217,5 @@
* Allocate the extra space in the buffer.
*/
- error = bread(ITOV(ip), lbprev, osize, NOCRED, &bp);
+ error = bread(vp, lbprev, osize, NOCRED, &bp);
if (error) {
brelse(bp);
@@ -295,5 +304,5 @@
if (bno > 0) {
bp->b_blkno = fsbtodb(fs, bno);
- if (!DOINGSOFTDEP(ITOV(ip)))
+ if (!DOINGSOFTDEP(vp))
ffs_blkfree(ip, bprev, (long)osize);
if (nsize < request)
@@ -319,4 +328,9 @@
* no space available
*/
+ if (fs->fs_pendingblocks > 0 && reclaimed == 0) {
+ reclaimed = 1;
+ softdep_request_cleanup(fs, vp);
+ goto retry;
+ }
ffs_fserr(fs, cred->cr_uid, "file system full");
uprintf("\n%s: write failed, file system is full\n", fs->fs_fsmnt);
Index: ffs_extern.h
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_extern.h,v
retrieving revision 1.30
diff -u -2 -r1.30 ffs_extern.h
--- ffs_extern.h 9 Jan 2000 22:40:02 -0000 1.30
+++ ffs_extern.h 27 Mar 2002 10:05:03 -0000
@@ -115,4 +115,5 @@
void softdep_load_inodeblock __P((struct inode *));
void softdep_freefile __P((struct vnode *, ino_t, int));
+int softdep_request_cleanup __P((struct fs *, struct vnode *));
void softdep_setup_freeblocks __P((struct inode *, off_t));
void softdep_setup_inomapdep __P((struct buf *, struct inode *, ino_t));
Index: ffs_softdep.c
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v
retrieving revision 1.57.2.11
diff -u -2 -r1.57.2.11 ffs_softdep.c
--- ffs_softdep.c 5 Feb 2002 18:46:53 -0000 1.57.2.11
+++ ffs_softdep.c 27 Mar 2002 10:12:48 -0000
@@ -508,7 +508,8 @@
static struct proc *filesys_syncer; /* proc of filesystem syncer process */
static int req_clear_inodedeps; /* syncer process flush some inodedeps */
-#define FLUSH_INODES 1
+#define FLUSH_INODES 1
static int req_clear_remove; /* syncer process flush some freeblks */
-#define FLUSH_REMOVE 2
+#define FLUSH_REMOVE 2
+#define FLUSH_REMOVE_WAIT 3
/*
* runtime statistics
@@ -703,5 +704,5 @@
if (wk == 0) {
FREE_LOCK(&lk);
- return (0);
+ return (-1);
}
WORKLIST_REMOVE(wk);
@@ -4561,4 +4562,39 @@
/*
+ * Called by the allocation routines when they are about to fail
+ * in the hope that we can free up some disk space.
+ *
+ * First check to see if the work list has anything on it. If it has,
+ * clean up entries until we successfully free some space. Because this
+ * process holds inodes locked, we cannot handle any remove requests
+ * that might block on a locked inode as that could lead to deadlock.
+ * If the worklist yields no free space, encourage the syncer daemon
+ * to help us. In no event will we try for longer than tickdelay seconds.
+ */
+int
+softdep_request_cleanup(fs, vp)
+ struct fs *fs;
+ struct vnode *vp;
+{
+ long starttime, needed;
+
+ needed = fs->fs_cstotal.cs_nbfree + fs->fs_contigsumsize;
+ starttime = time_second + tickdelay;
+ if (UFS_UPDATE(vp, 1) != 0)
+ return (0);
+ while (fs->fs_pendingblocks > 0 && fs->fs_cstotal.cs_nbfree <= needed) {
+ if (time_second > starttime)
+ return (0);
+ if (num_on_worklist > 0 &&
+ process_worklist_item(NULL, LK_NOWAIT) != -1) {
+ stat_worklist_push += 1;
+ continue;
+ }
+ request_cleanup(FLUSH_REMOVE_WAIT, 0);
+ }
+ return (1);
+}
+
+/*
* If memory utilization has gotten too high, deliberately slow things
* down and speed up the I/O processing.
@@ -4595,4 +4631,10 @@
/*
+ * Next, we attempt to speed up the syncer process. If that
+ * is successful, then we allow the process to continue.
+ */
+ if (speedup_syncer() && resource != FLUSH_REMOVE_WAIT)
+ return(0);
+ /*
* If we are resource constrained on inode dependencies, try
* flushing some dirty inodes. Otherwise, we are constrained
@@ -4613,4 +4655,5 @@
case FLUSH_REMOVE:
+ case FLUSH_REMOVE_WAIT:
stat_blk_limit_push += 1;
req_clear_remove += 1;
--
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr
FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Wed Mar 27, 2002 8:51 pm Post subject:
Re: [PATCH] MFC the full filesystem softupdates fix ?
|
|
|
I think Kirk meant "-stable", not "-current"; in any case, I'd
like to see it handled and brought back into -stable anyway. I
look at -stable as a pruned -current. Some of the growth in
-current should/will never see the light of day in a realease...
-- Terry
Kirk McKusick wrote:
| Quote: |
If it was easy as your patch, there would be no problem in
putting it in. The problem is that -current does not have
the code to maintain the fs_pendingblocks variable. At a
minimum you would have to add that code as well. It is a
good deal more extensive, though at this point well enough
tested that I am less fearful of adding it.
Kirk McKusick
=-=-=-=-=-=
Date: Wed, 27 Mar 2002 11:19:47 +0100
From: Ollivier Robert <roberto@eurocontrol.fr
To: mckusick@mckusick.com
Cc: arch@FreeBSD.ORG
Subject: [PATCH] MFC the full filesystem softupdates fix ?
Following some discussions in the French fr.comp.os.bsd newsgroup about
softupdates and the full filesystem problem (which is fixed in CURRENT
thanks to you), here a proposed diff to merge the fix into STABLE.
Can you (and -arch) review it ? It would be nice to have this fixed in
STABLE as well.
Thanks.
Index: ffs_alloc.c
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_alloc.c,v
retrieving revision 1.64.2.2
diff -u -2 -r1.64.2.2 ffs_alloc.c
--- ffs_alloc.c 21 Sep 2001 19:15:21 -0000 1.64.2.2
+++ ffs_alloc.c 27 Mar 2002 10:08:29 -0000
@@ -107,5 +107,5 @@
register struct fs *fs;
ufs_daddr_t bno;
- int cg;
+ int cg, reclaimed;
#ifdef QUOTA
int error;
@@ -124,4 +124,6 @@
panic("ffs_alloc: missing credential");
#endif /* DIAGNOSTIC */
+ reclaimed = 0;
+retry:
if (size == fs->fs_bsize && fs->fs_cstotal.cs_nbfree == 0)
goto nospace;
@@ -155,4 +157,9 @@
#endif
nospace:
+ if (fs->fs_pendingblocks > 0 && reclaimed == 0) {
+ reclaimed = 1;
+ softdep_request_cleanup(fs, ITOV(ip));
+ goto retry;
+ }
ffs_fserr(fs, cred->cr_uid, "file system full");
uprintf("\n%s: write failed, file system is full\n", fs->fs_fsmnt);
@@ -177,7 +184,7 @@
struct buf **bpp;
{
- register struct fs *fs;
+ struct fs *fs;
struct buf *bp;
- int cg, request, error;
+ int cg, request, error, reclaimed;
ufs_daddr_t bprev, bno;
@@ -198,4 +205,6 @@
if (cred->cr_uid != 0 &&
freespace(fs, fs->fs_minfree) - numfrags(fs, nsize - osize) < 0)
+ reclaimed = 0;
+retry:
goto nospace;
if ((bprev = ip->i_db[lbprev]) == 0) {
@@ -208,5 +217,5 @@
* Allocate the extra space in the buffer.
*/
- error = bread(ITOV(ip), lbprev, osize, NOCRED, &bp);
+ error = bread(vp, lbprev, osize, NOCRED, &bp);
if (error) {
brelse(bp);
@@ -295,5 +304,5 @@
if (bno > 0) {
bp->b_blkno = fsbtodb(fs, bno);
- if (!DOINGSOFTDEP(ITOV(ip)))
+ if (!DOINGSOFTDEP(vp))
ffs_blkfree(ip, bprev, (long)osize);
if (nsize < request)
@@ -319,4 +328,9 @@
* no space available
*/
+ if (fs->fs_pendingblocks > 0 && reclaimed == 0) {
+ reclaimed = 1;
+ softdep_request_cleanup(fs, vp);
+ goto retry;
+ }
ffs_fserr(fs, cred->cr_uid, "file system full");
uprintf("\n%s: write failed, file system is full\n", fs->fs_fsmnt);
Index: ffs_extern.h
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_extern.h,v
retrieving revision 1.30
diff -u -2 -r1.30 ffs_extern.h
--- ffs_extern.h 9 Jan 2000 22:40:02 -0000 1.30
+++ ffs_extern.h 27 Mar 2002 10:05:03 -0000
@@ -115,4 +115,5 @@
void softdep_load_inodeblock __P((struct inode *));
void softdep_freefile __P((struct vnode *, ino_t, int));
+int softdep_request_cleanup __P((struct fs *, struct vnode *));
void softdep_setup_freeblocks __P((struct inode *, off_t));
void softdep_setup_inomapdep __P((struct buf *, struct inode *, ino_t));
Index: ffs_softdep.c
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v
retrieving revision 1.57.2.11
diff -u -2 -r1.57.2.11 ffs_softdep.c
--- ffs_softdep.c 5 Feb 2002 18:46:53 -0000 1.57.2.11
+++ ffs_softdep.c 27 Mar 2002 10:12:48 -0000
@@ -508,7 +508,8 @@
static struct proc *filesys_syncer; /* proc of filesystem syncer process */
static int req_clear_inodedeps; /* syncer process flush some inodedeps */
-#define FLUSH_INODES 1
+#define FLUSH_INODES 1
static int req_clear_remove; /* syncer process flush some freeblks */
-#define FLUSH_REMOVE 2
+#define FLUSH_REMOVE 2
+#define FLUSH_REMOVE_WAIT 3
/*
* runtime statistics
@@ -703,5 +704,5 @@
if (wk == 0) {
FREE_LOCK(&lk);
- return (0);
+ return (-1);
}
WORKLIST_REMOVE(wk);
@@ -4561,4 +4562,39 @@
/*
+ * Called by the allocation routines when they are about to fail
+ * in the hope that we can free up some disk space.
+ *
+ * First check to see if the work list has anything on it. If it has,
+ * clean up entries until we successfully free some space. Because this
+ * process holds inodes locked, we cannot handle any remove requests
+ * that might block on a locked inode as that could lead to deadlock.
+ * If the worklist yields no free space, encourage the syncer daemon
+ * to help us. In no event will we try for longer than tickdelay seconds.
+ */
+int
+softdep_request_cleanup(fs, vp)
+ struct fs *fs;
+ struct vnode *vp;
+{
+ long starttime, needed;
+
+ needed = fs->fs_cstotal.cs_nbfree + fs->fs_contigsumsize;
+ starttime = time_second + tickdelay;
+ if (UFS_UPDATE(vp, 1) != 0)
+ return (0);
+ while (fs->fs_pendingblocks > 0 && fs->fs_cstotal.cs_nbfree <= needed) {
+ if (time_second > starttime)
+ return (0);
+ if (num_on_worklist > 0 &&
+ process_worklist_item(NULL, LK_NOWAIT) != -1) {
+ stat_worklist_push += 1;
+ continue;
+ }
+ request_cleanup(FLUSH_REMOVE_WAIT, 0);
+ }
+ return (1);
+}
+
+/*
* If memory utilization has gotten too high, deliberately slow things
* down and speed up the I/O processing.
@@ -4595,4 +4631,10 @@
/*
+ * Next, we attempt to speed up the syncer process. If that
+ * is successful, then we allow the process to continue.
+ */
+ if (speedup_syncer() && resource != FLUSH_REMOVE_WAIT)
+ return(0);
+ /*
* If we are resource constrained on inode dependencies, try
* flushing some dirty inodes. Otherwise, we are constrained
@@ -4613,4 +4655,5 @@
case FLUSH_REMOVE:
+ case FLUSH_REMOVE_WAIT:
stat_blk_limit_push += 1;
req_clear_remove += 1;
--
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr
FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
|
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Ollivier Robert
*nix forums beginner
Joined: 21 Mar 2002
Posts: 19
|
| Posted: Thu Mar 28, 2002 10:10 am Post subject:
Re: [PATCH] MFC the full filesystem softupdates fix ?
|
|
|
According to Kirk McKusick:
| Quote: | If it was easy as your patch, there would be no problem in
putting it in. The problem is that -current does not have
the code to maintain the fs_pendingblocks variable. At a
minimum you would have to add that code as well. It is a
good deal more extensive, though at this point well enough
|
I've now seen that...
| Quote: | tested that I am less fearful of adding it.
|
If we take into consideration the fact that 5.0-R won't be there till
October/November, do you think it would be possible to put that fix and
maybe snapshots into 4-STABLE?
--
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr
FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Kirk McKusick
*nix forums beginner
Joined: 19 Mar 2002
Posts: 40
|
| Posted: Thu Mar 28, 2002 8:30 pm Post subject:
Re: [PATCH] MFC the full filesystem softupdates fix ?
|
|
|
Date: Thu, 28 Mar 2002 12:10:07 +0100
From: Ollivier Robert <roberto@eurocontrol.fr>
To: Kirk McKusick <mckusick@beastie.mckusick.com>
Cc: arch@FreeBSD.ORG
Subject: Re: [PATCH] MFC the full filesystem softupdates fix ?
In-Reply-To: <200203272134.g2RLYTD97258@beastie.mckusick.com>
According to Kirk McKusick:
| Quote: | > If it was easy as your patch, there would be no problem in
> putting it in. The problem is that -current does not have
> the code to maintain the fs_pendingblocks variable. At a
> minimum you would have to add that code as well. It is a
> good deal more extensive, though at this point well enough
|
I've now seen that...
| Quote: | > tested that I am less fearful of adding it.
|
If we take into consideration the fact that 5.0-R won't be
there till October/November, do you think it would be
possible to put that fix and maybe snapshots into 4-STABLE?
The is no chance that snapshots would move into -current. They
touch thousands of lines of code.
If you want to pull over the pending block changes, I enclose
the relevent delta below.
Kirk McKusick
=-=-=-=-=-=-=
From: Kirk McKusick <mckusick@FreeBSD.org>
Date: Tue, 8 May 2001 00:42:20 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/ufs/ffs fs.h softdep.h ffs_softdep.c
ffs_softdep_stub.c ffs_inode.c ffs_vfsops.c src/sys/ufs/ufs
ufs_extern.h inode.h ufs_inode.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-committers@FreeBSD.org
mckusick 2001/05/08 00:42:20 PDT
Modified files:
sys/ufs/ffs fs.h softdep.h ffs_softdep.c
ffs_softdep_stub.c ffs_inode.c
ffs_vfsops.c
sys/ufs/ufs ufs_extern.h inode.h ufs_inode.c
Log:
When running with soft updates, track the number of blocks and files
that are committed to being freed and reflect these blocks in the
counts returned by statfs (and thus also by the `df' command). This
change allows programs such as those that do news expiration to
know when to stop if they are trying to create a certain percentage
of free space. Note that this change does not solve the much harder
problem of making this to-be-freed space available to applications
that want it (thus on a nearly full filesystem, you may still
encounter out-of-space conditions even though the free space will
show up eventually). Hopefully this harder problem will be the
subject of a future enhancement.
Revision Changes Path
1.22 +4 -2 src/sys/ufs/ffs/fs.h
1.12 +6 -3 src/sys/ufs/ffs/softdep.h
1.94 +59 -2 src/sys/ufs/ffs/ffs_softdep.c
1.16 +10 -1 src/sys/ufs/ffs/ffs_softdep_stub.c
1.71 +3 -1 src/sys/ufs/ffs/ffs_inode.c
1.153 +37 -4 src/sys/ufs/ffs/ffs_vfsops.c
1.34 +2 -1 src/sys/ufs/ufs/ufs_extern.h
1.34 +4 -5 src/sys/ufs/ufs/inode.h
1.36 +3 -1 src/sys/ufs/ufs/ufs_inode.c
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Thu Mar 28, 2002 9:44 pm Post subject:
Re: UFS snapshots in current
|
|
|
At 1:30 PM -0800 3/28/02, Kirk McKusick wrote:
| Quote: | The is no chance that snapshots would move into -current.
They touch thousands of lines of code.
|
aside: s/current/stable/ ...
More useful question: what should I look at for info on
using snapshots? It seems to me I should already know,
but I have to admit I don't. What's worse, I think I
even asked this once before...
In any case, I'd like to try them out (on current) for
some ideas I have.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Kirk McKusick
*nix forums beginner
Joined: 19 Mar 2002
Posts: 40
|
| Posted: Thu Mar 28, 2002 9:50 pm Post subject:
Re: UFS snapshots in current
|
|
|
Date: Thu, 28 Mar 2002 17:44:45 -0500
To: Kirk McKusick <mckusick@beastie.mckusick.com>
From: Garance A Drosihn <drosih@rpi.edu>
Subject: Re: UFS snapshots in current
Cc: arch@FreeBSD.ORG
At 1:30 PM -0800 3/28/02, Kirk McKusick wrote:
| Quote: | >The is no chance that snapshots would move into -current.
>They touch thousands of lines of code.
|
aside: s/current/stable/ ...
Same brain-fault twice in two days.
More useful question: what should I look at for info on
using snapshots? It seems to me I should already know,
but I have to admit I don't. What's worse, I think I
even asked this once before...
In any case, I'd like to try them out (on current) for
some ideas I have.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
General references are found at:
http://www.mckusick.com/softdep/index.html
The soft updates paper has a section on snapshots. The background
fsck paper goes into snapshots (and their general usage) in a bit
more detail, so is likely to be more useful.
Kirk McKusick
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Sun Mar 31, 2002 3:01 am Post subject:
Re: UFS snapshots in current
|
|
|
At 2:50 PM -0800 3/28/02, Kirk McKusick wrote:
| Quote: | From: Garance A Drosihn <drosih@rpi.edu
More useful question: what should I look at for
info on using snapshots?
General references are found at:
http://www.mckusick.com/softdep/index.html
The soft updates paper has a section on snapshots. The
background fsck paper goes into snapshots (and their
general usage) in a bit more detail, so is likely to
be more useful.
|
Okay, well, I was trying this out and I had something
odd happen. As I sit here waiting for my PC to return
to life, I'll ask if what I was trying to do something
which would be a BadIdea(tm).
I wanted to use a snapshot to "freeze" the system in
time before doing a large-scale set of changes. So, I
created a snapshot of /usr. I then did a 'cvs update'
of /usr/src, and checked how the snapshot worked. It
seemed to be doing just exactly what I wanted. I then
got interrupted and forgot about the snapshot. I may
have also done a reboot, but I'm not sure about that.
Days pass, I come back, do another 'cvs update' of the
latest sources. I buildworld, buildkernel, installkernel.
So far no problem (note that /usr/obj is on a separate
partition). I reboot, and go to do an installworld.
It goes merrily along for awhile, and then just stops.
After letting it sit there for about 15 minutes, I
attention out of the buildworld. It had not used a
lot of cpu time. so, I tried it again. it went a
few lines and then stopped again.
I finally decided to just reboot. The shutdown started,
and then got stuck at 'Writing entropy file'. I then
hit the power button. It didn't power off! I had to
unplug the machine to get it to reboot.
After it came back up, I removed the checkpoint file.
I forget how large it was, but it was pretty large.
Before removing it, I did a 'df -k -i', and /usr had
plenty of spare filespace and spare inodes. I didn't
know what else I should check for. By then the system
told me that I had to do an fsck of /usr by hand, so
I've done that, and now have 1500 files in lost+found.
It happens I have an exact duplicate of my current
system in a different set of partitions, so one way or
another I can get the system back to what I need. But
the main question is: Could my problems have been due to
that snapshot being active when I did the 'installworld'?
I only *meant* it to be there during the 'cvs update',
buildworld, and buildkernel, but I had forgotten it
was there. It's hard to believe that this was due to
any of the changes made to current in the past week.
And if it is a bad idea, how hard would it be to get it
to fail a little more gracefully? :-)
Also, if this had worked, I probably would have duplicated
this new system to my backup partitions. From what I've
read of the paper, I think that would not cause a problem
(other than maybe wasting disk space), because a plain copy
(using pax) wouldn't add the snapshot file to the list of
snapshots in the superblock of the destination partition.
True?
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Alfred Perlstein
*nix forums addict
Joined: 19 Mar 2002
Posts: 67
|
| Posted: Sun Mar 31, 2002 3:50 am Post subject:
Re: UFS snapshots in current
|
|
|
* Garance A Drosihn <drosih@rpi.edu> [020330 20:01] wrote:
| Quote: | At 2:50 PM -0800 3/28/02, Kirk McKusick wrote:
From: Garance A Drosihn <drosih@rpi.edu
More useful question: what should I look at for
info on using snapshots?
General references are found at:
http://www.mckusick.com/softdep/index.html
The soft updates paper has a section on snapshots. The
background fsck paper goes into snapshots (and their
general usage) in a bit more detail, so is likely to
be more useful.
Okay, well, I was trying this out and I had something
odd happen. As I sit here waiting for my PC to return
to life, I'll ask if what I was trying to do something
which would be a BadIdea(tm).
|
[snip]
Looks like you hit one of the snapshot deadlock conditions, Dr
McKusick recently introduced a fix for one of the deadlocks so this
may not happen again...
-Alfred
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Sun Mar 31, 2002 5:50 am Post subject:
Re: UFS snapshots in current
|
|
|
At 8:50 PM -0800 3/30/02, Alfred Perlstein wrote:
| Quote: | Looks like you hit one of the snapshot deadlock conditions,
Dr McKusick recently introduced a fix for one of the
deadlocks so this may not happen again...
|
In the past week? The "old" current system which I had
been running should have been from March 26th, when I
rebuilt it to see if it would fix my vmware problems
(which it did...). I don't see any commits wrt softupdates
which are that recent.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Kirk McKusick
*nix forums beginner
Joined: 19 Mar 2002
Posts: 40
|
| Posted: Sun Mar 31, 2002 8:14 pm Post subject:
Re: UFS snapshots in current
|
|
|
Date: Sun, 31 Mar 2002 01:50:10 -0500
To: Alfred Perlstein <bright@mu.org>
From: Garance A Drosihn <drosih@rpi.edu>
Subject: Re: UFS snapshots in current
Cc: Kirk McKusick <mckusick@beastie.mckusick.com>, arch@FreeBSD.ORG
At 8:50 PM -0800 3/30/02, Alfred Perlstein wrote:
| Quote: | >Looks like you hit one of the snapshot deadlock conditions,
>Dr McKusick recently introduced a fix for one of the
>deadlocks so this may not happen again...
|
In the past week? The "old" current system which I had
been running should have been from March 26th, when I
rebuilt it to see if it would fix my vmware problems
(which it did...). I don't see any commits wrt softupdates
which are that recent.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
All of the above is basically correct. Your use of a snapshot
over a long period of time and in particular over a CVS update,
build world, and install world should not cause trouble (other
than perhaps a large amount of disk space being used). There
is no problem with rebooting, provided that the filesystem with
the snapshot is cleanly unmounted. Snapshots can be made to
survive panics by setting `sysctl -w debug.dopersistence=1'
but at a non-trivial performance cost. The problem that you
encountered was most likely a deadlock in the snapshot code.
I fixed one deadlock last January, but am aware of at least
one more that is still there. I have a fairly good idea on how
to fix it, but have not yet had the time to work on that fix.
On your final question about making a pax archive, if you make
an archive of the real filesystem, the snapshot will show up
on the archive as a file the size of the filesystem partition.
If you mount the snapshot and then make an archive of that
filesystem, then the snapshot(s) in the archive will show up
as zero length files.
Kirk McKusick
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Mon Apr 01, 2002 12:12 am Post subject:
Re: UFS snapshots in current
|
|
|
At 2:14 PM -0800 3/31/02, Kirk McKusick wrote:
| Quote: | All of the above is basically correct. Your use of a snapshot
over a long period of time and in particular over a CVS update,
build world, and install world should not cause trouble (other
than perhaps a large amount of disk space being used). There
is no problem with rebooting, provided that the filesystem with
the snapshot is cleanly unmounted.
|
I really think this snapshot capability is great. Combined
with the huge disks we can buy these days, I think snapshots
will be useful in many ways that we're not even thinking of yet.
| Quote: | I fixed one deadlock last January, but am aware of at least
one more that is still there. I have a fairly good idea on how
to fix it, but have not yet had the time to work on that fix.
|
Okay, thanks.
| Quote: | On your final question about making a pax archive, if you make
an archive of the real filesystem, the snapshot will show up
on the archive as a file the size of the filesystem partition.
If you mount the snapshot and then make an archive of that
filesystem, then the snapshot(s) in the archive will show up
as zero length files.
|
Hmm. Is there any way for a regular user-land process to tell
if a given file is a snapshot? Something in the stat() info,
or some other way to tell? I have no urgent need for it, but
it seems like it would be useful.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Alfred Perlstein
*nix forums addict
Joined: 19 Mar 2002
Posts: 67
|
| Posted: Mon Apr 01, 2002 12:38 am Post subject:
Re: UFS snapshots in current
|
|
|
* Garance A Drosihn <drosih@rpi.edu> [020331 18:12] wrote:
| Quote: |
Hmm. Is there any way for a regular user-land process to tell
if a given file is a snapshot? Something in the stat() info,
or some other way to tell? I have no urgent need for it, but
it seems like it would be useful.
|
This probably isn't exactly what you're looking for, but you could
check the file's ctime against the ctime of the snapshot file.
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
| Posted: Mon Apr 01, 2002 2:48 am Post subject:
Re: UFS snapshots in current
|
|
|
On Sun, 31 Mar 2002, Garance A Drosihn wrote:
| Quote: | Hmm. Is there any way for a regular user-land process to tell if a
given file is a snapshot? Something in the stat() info, or some other
way to tell? I have no urgent need for it, but it seems like it would
be useful.
|
Look for the SF_SNAPSHOT flag. I don't recall if this is exported via the
flags field via stat(), but it may well be.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Kirk McKusick
*nix forums beginner
Joined: 19 Mar 2002
Posts: 40
|
| Posted: Mon Apr 01, 2002 4:07 am Post subject:
Re: UFS snapshots in current
|
|
|
Date: Sun, 31 Mar 2002 21:12:13 -0500
To: Kirk McKusick <mckusick@beastie.mckusick.com>
From: Garance A Drosihn <drosih@rpi.edu>
Subject: Re: UFS snapshots in current
Cc: arch@FreeBSD.ORG
At 2:14 PM -0800 3/31/02, Kirk McKusick wrote:
| Quote: | >On your final question about making a pax archive, if you make
>an archive of the real filesystem, the snapshot will show up
>on the archive as a file the size of the filesystem partition.
>If you mount the snapshot and then make an archive of that
>filesystem, then the snapshot(s) in the archive will show up
>as zero length files.
|
Hmm. Is there any way for a regular user-land process to tell
if a given file is a snapshot? Something in the stat() info,
or some other way to tell? I have no urgent need for it, but
it seems like it would be useful.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
You can determine if a file is a snapshot by doing a stat
and checking for the SF_SNAPSHOT bit being set in the
st_flags field.
Kirk McKusick
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 5:45 am | All times are GMT
|
|
Loans | Loans | Secured Loans | The eBay Song | Neopets Cheats, Games and Neopoints
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
